I am trying to write an application that will access, and change, entries in a user's calendars. The changes are driven by fairly complex rules, that the user can define.
My question, before I spend too much time developing, is whether I should go with core data. A lot of the model will be handled by core data, but I will need to access a lot of stored info and then change it. Would this be a problem with core data?
It would help if I had a better understanding of core data, but at this point I do not :( Could someone comment on the possibility to perform changes on the model data, when using core data? I'd hate to be a few months into the development, and discover I made the wrong choice!
The recently released WWDC media collection contains an audio presentation from 2005 when the Core Data framework was released as part of the OS X frameworks. The presentation covers Core Data's primary goals, design principles and architecture. It also discusses a set of sample applications (the recipy apps). The collection is available through iTunesU. It is worthwhile to listen to to grasp the framework's working principles.
I've been working with Core Data for a while now. I find it easy to work with, well integrated into Xcode, stable and so far has been a true contributor to my productivity. It offers various storage options for your data (binary, XML - very easy to work with during development - and SQLite), very decent tool support, easy model migration for small changes, complex migration available for major model changes with some extra effort.
You will have to be aware of the fact that Core Data is NOT a RDBMS nor a RDBMS mapping tool. It is an object graph and persistence framework, which is a different thing. If you ignore this fact, Core Data might give you performance penalties.
Making schema changes isn't harder with CoreData than with most other data frameworks. CoreData can handle many simple changes to your data model on its own. When it can't figure out the right thing to do, you can write custom migrations.
In my experience, CoreData usually makes data-intensive apps easier to write and maintain, with a very slight loss in flexibility that you usually won't miss.
Related
A partner has a website that needs to be rebuild from scratch as it simply can't cope with the large number of visitors (currently build using SilverStripe). The site should be able to deal with 5 million or more members using 20+ languages.
We were considering using CodeIgniter or YII because from research both appear to be excellent performers. However several people advised that we should consider the latest version of Joomla for this. For small websites we are happy to use Joomla but for a heavy load website our feeling says that we have to stay away from that. We are however not able to find any comparison between both from a performance point of view but we do require good arguments why Joomla would or would not at all be a good candidate for this. One comparison can be found here: http://vschart.com/compare/yii/vs/joomla/vs/codeigniter however this doens't tell me what to expect when the number of visitors is really high.
Can some advise how Joomla compares to CodeIngitor or YII considering that the site will receive a very high number of vistors and will use a 20+ languages (for silverstripe we build a translator module as the build in CMS was not usefull when using so many translators).
When you're dealing with a site of that scale, it's probably best not to shift to Joomla. Joomla can handle a fair bit, but I'd suggest that it would be far easier to have a Joomla site that large when the site has been adapting as the traffic increases.
Part of what makes your question hard to answer is that we don't know much about what your current site does.
Is it mainly a CMS? If so, Drupal may be a decent fit for you.
Is it a custom web application? It sounds like it could be, based on the number of translations you're handling.
Is it somewhere in-between? This could also be what you're dealing with.
If you're looking at either of the bottom two options, yes, shifting away from SilverStripe (but not to Joomla) sounds like it might be a good thing.
Given the volume of traffic you're dealing with, it sounds like you probably already have a revenue stream and a development team. In that case, it might be worth having a few of your developers play with CodeIgniter and Yii and see what they think.
I wrote up a detailed answer to a question about what type of framework to choose a while ago, which you can look over here:
https://stackoverflow.com/questions/10095906/yii-or-zend-or-other-frameworks-under-the-following-requirements/10115678#10115678
I'm a Yii fan, having checked out a bunch of other frameworks. Regardless of which framework you use, I'd like to offer one piece of advice that I've found key on all projects I've worked on.
You want to work with objects, not data arrays
The reason for the above is that your models (and the objects they produce) can end up having your business logic built into them. Doing this makes life far, far easier in the long run. A great book on the subject, aimed at manager's and quite high-level (there is no code, although there might be a few lines of psuedo-code), is Object Technology: A Manager's Guide. I'd highly recommend it.
Framework thoughts
CakePHP
I started dabbling with CakePHP until I found out it didn't hand back objects (just arrays), at which point I ran screaming.
CodeIgniter
Looking at what CodeIgniter has for database model support, I think you would quickly hit its limitations with a site of your size, so would recommend against it. And having EllisLabs deciding to leave CodeIgniter behind (see their website for more details) is not a good sign. The signs say stay away.
Of the PHP frameworks out there, these are the ones I hear the most things about:
Symfony 2
Yii (disclosure: I work with this one daily)
Laravel
Symfony
From what I can see of it, has been a huge stimulus to the PHP community and many best practices have come out of that community. Unit testing, Composer, pushes for PSR-1/2, the ideal of modularity of code (some of their core code is ending up in Drupal 8) are all great things that have spurred the PHP community into writing code that's better than spaghetti code. With that said, it feels kind of heavy and enterprise-y and looked to have a pretty heavy learning curve.
Yii
When I was looking for a framework, I had a lot of legacy code that needed migration. Yii's way of handling things, although opinionated at times, has done a lot for me as far as exposing me to good practices that are used heavily on the web. Highly recommended as well.
Laravel
When I was looking for a framework (2+ years ago), Laravel didn't exist. It's apparently quite slick and cutting edge (haven't looked at it yet, I've been busy landing new work regularly in the Yii world), but I am interested in dabbling with it. That said, here's a thoughtful article about Laravel and couple of considerations that I've wondered about.
The main developer, Taylor Ortwell, seemed to be a dominant force. That's a great thing while he's making money doing this and enjoying it. Not sure what would happen to the framework if he decided to do something else.
The speed of development on the framework is an awesome thing and means that all sorts of creative juices are flowing. It's a great place to go look at cool new things. That said, you're going to want your developers to be able to easily find information about the framework they're working with, which in 3-6 months may be severely out of date in the Laravel community. The Ruby on Rails community has the same type of good/bad problem when I've looked around over there; there is so much information about the new stuff that sometimes it's hard to find information about the version of the framework you're dealing with.
That said, there are lots of cool choices out there :-) I should probably wrap up, as this has gone on far longer than I'd intended. Let us know what you end up deciding and how it ends up going.
How big is the site really? Bigger than joomla.org?
Are you talking about big in terms of the amount of content in the database or in terms of the number of visitors.
Joomla really does not have problems with scale unless you are on an older version of MySQL in which case it slows down.
It depends on what kind of application you want.
If you want a CMS, Joomla is the way to go. Because this is what it was build for.
If you are about to create a real "custom" application Yii/Codeigniter is the way to go. (This is what yii was build for)
Regarding performance, from my expericnece Yii is a lot faster, because it comes with way less overhead. You can build the application just as you need it.
Well it's like compare green and salty. Really joomla is CMS, and Yii and CI are frameworks. If you considering make highload on joomla - it's not your job.
If you have high frontend load - maybe watch on js frameworks? Yii+backbone.js or ext.js for frontend is awesome, since you'll move alot to clientside.
CI is dead. I honestly like it, but its dead already. No extensions, no namespaces in future, nothing.
I can say + of Yii:
*faster then CI;
*have great documentation and wiki articles;
*have great and active community and developers;
What else i can add? Active record is good for small databases, but not usable for highloads. Also as i said on yii you can easily make js framework+yii composition. Yii have good caching system. Long time support of stable versions.
I personally manage highload now, but its more backend/api/database. 150+ thousands database records daily, 300+ thousands requests to api, 50 milions records data table. It works like a clock for more then 2 months already.
Choose what you like, or write on native php if its really big system - best choice from practice.
Joomla is an award-winning content management system (CMS), which
enables you to build Web sites and powerful online applications. Many
aspects, including its ease-of-use and extensibility, have made Joomla
the most popular Web site software available. Best of all, Joomla is
an open source solution that is freely available to everyone.
CodeIgniter is an Application Development Framework - a toolkit - for
people who build web sites using PHP. Its goal is to enable you to
develop projects much faster than you could if you were writing code
from scratch, by providing a rich set of libraries for commonly needed
tasks, as well as a simple interface and logical structure to access
these libraries. CodeIgniter lets you creatively focus on your project
by minimizing the amount of code needed for a given task.
Yii is a free, open-source Web application development framework
written in PHP5 that promotes clean, DRY design and encourages rapid
development. It works to streamline your application development and
helps to ensure an extremely efficient, extensible, and maintainable
end product.
Joomla can't compare with CodeIgniter / Yii. But, If you need any CMS for your project, you can use Joomla (or maybe Wordpress). If you want to create any web application, then you need to decide for any PHP Framework. I use CodeIgniter for years, and I like it. They have a huge community, and the best user guide. Yii also has a great community and a lot of features. So, you can decide depending on you demand.
I am looking into developing a commercial application using PHP. Since I have experience in CodeIgniter and it has been working well for me, I decided to use it. Now, if ever my application comes to a point that it needs to grow and have to have custom modifications in the platform, is it possible to modify the CodeIgniter source code to the point that it's far from the original?
I'd strongly recommend not modifying the source code as this is the back bone of the application will make updating to futures releases of codeigniter impossible.
Instead you should be creating your own classes/libraries that extend the core bases. This is best practice.
The codeigniter users guide has some fantastic information regarding this, http://codeigniter.com/user_guide/general/creating_libraries.html
Good luck.
Don't modify it, extend it. Ellislab is good about releasing bug fixes and patches, and the last thing you want is to have to re-engineer all the updates into your new hybrid everytime they release updated source code. Plus, different features and bug fixes are released at different paces for the core and reactor, so unless you plan to lock your framework in at the current version, extending is the way to go.
The good news is CI is built for and encourages extensions of the source. The system folder and the application folder separation are a clear indication of how you should segregate your enhancements from the base libraries.
CodeIgniter is written in PHP. You can completely rewrite the framework anyway you like. So the answer is "yes".
There are many big websites that were written in a different language or build on a framework when they started and have been rewritten many times since. I think a lot of developers (mostly freelancers) are over-thinking when starting out. When I start a project, then I try to get it done and get it out in the web asap. If a website starts taking of - and most of the times start making you money - then you can always take the time to rewrite it.
I think it is a lot more important to spend time when you plan and design your database and tables. I think it is a lot harder to redo parts of your database later on then it is to rewrite the code that uses the data.
Just my 2 cents.
If you have used CI, then you should know that being a PHP framework that all of the source-code is there in the download, furthermore opening the system and application folders and looking through there will tell you a lot. Yes all of the source is there in plain English (plain programming English) and not only is it in plain English but has been extensively documented inside and out (literally that is in the source and in the user-guide). CI gained initial fame from that simple fact, that all code is extensively and meticulously documented.
Beyond all that, the question itself raises concerns that maybe you should study CI a bit further before writing commercial applications using it. Ci is a powerful and very easy to use PHP framework, but it is not a WYSIWYG. In my opinion, a coder should know his tools inside and out in order to be able to create a solid secure and trusted application. The first measure of which is to read the user manual, you should know at the very least everything in it, and since there are 12 sections in it that cover everything from extending CI libraries to creating your own libraries, and everything in between I would say you need to spend a little more time with it.
I want to say though, I am not being rude or trying to shame you in any way I am simply saying that you should learn the framework a bit more before venturing into a commercial application using it.
In the early days of PHP people realized how amazingly easy it was to use and how fast you could write an application with it. At the time the major options where very difficult for new and hobby programmers to use or involved expensive software to run, PHP was free, easy to learn and most of all ran on a free OS. It also took hardly any setup to get going, you could download PHP and essentially be programming in minutes. All of these factors lead to the almost destruction of the language.
Entry level programmers were destroying it with bits of code taken from other applications, never knowing (or caring) what the code actually did beyond the simple fact that it did what they wanted at the time, never considering or even investigating if the code might be harmful. Because of this practice PHP applications that had grown to Goliath sized websites, taking thousands of hits an hour were:
beginning to crash
being hacked to reveal sensitive customer/client data
generally crumbling all around the web
All because since the language was so easy to use that people had taken advantage of it and failed to take time to learn it. PHP was becoming a joke to other professional programmers and wasn't even thought of as a viable application language by many who had dubbed it "the copy and paste" language.
So my advice to you, please take the time to know your tools inside and out, what makes them tick, if they have any gotchas and where they are vulnerable. I understand that in order to learn a language to a professional level you have to build with it so I suggest that you take it slow with CI stick to the core for now. Trust me when I say that even in its purest form CI is an amazing and powerful tool that in the right hands can create awesome powerful web application, but in the uneducated/inexperienced hands it can create havoc and destruction.
So (stepping off of the soap box) I simply ask that if you are serious about creating commercial applications period that you take your time and learn your tools/language become as close to an expert on them as possible. I gurentee that if you do that you will always have work when you need it and you will spend less hours beating your head against the table or worse explaining to a client why their site is down.
I truly wish you good luck, just slow down and learn your trade and you will do just fine.
Yes, Codeigniter is an open source framework. However, I would advise against modifying the core of Codeigniter, as most files can be extended and rewritten safely without modifying the core files which will cause you headaches if you ever decide to update.
To extend a core class by default you would do this in Codeigniter. We'll extended the parser class for this example, but this applies to all classes pretty much. This link in the comprehensive user guide will give you all the information you need to extended and overload methods inside of a Codeigniter core class: http://codeigniter.com/user_guide/general/core_classes.html
In my company they are finally (about time...) considering to convert one of our best selling apps from a 2-tier to 3-tier architecture, both on logical (Presentation, Business and Data layers) as well as physical level. Probably we will go for either a Delphi-Delphi-Oracle or a Delphi-Java-Oracle approach for the change.
This is a relatively old and large app that has been created and modified for a long time before I began working there. Refactoring, except for when something had to be changed, was usually never considered. Also, business logic is present in both of the actual tiers... sigh.
The physical change does not bother me much but the logical change will be kind of a passage through Hell. In order to smooth it as much as possible I would like to investigate about which Delphi components suit better for a 3-tier model.
¿Which alternatives would you consider to use?
Another good n-tier framework library is kbmMW from components4developers: http://components4developers.com/
We've recently converted our 2 tier Delphi app to 3 tier using RemObjects DataAbstract. While the initial learning curve was quite steep, we are absolutely delighted with the results.
DataAbstract lets you forget about the underlying nuts and bolts of database and network connectivity and concentrate on the business logic. It allows you to create an abstract service layer that provides your server clients with a nice API. Using this API we connect to the server using both a Delphi and a Delphi Prism ASP.NET client.
I've found RemObjects pretty usable. They have also DataAbstract built top on it, but I haven't used it.
Have you ever considered DataSnap XE?
Many poeple have online startups in their head that may potentially attracts millions, but most of the time you will only have minimal budget (time and resource) to start with so you want to have it delivered within a year's time. Short after launch, you are bound to perform one or a series of upgrades that may include: code refactor to newer foundation, adding hierarchy(ies) in software architecture or restructure database(s). This cycle of upgrade/refactor continues as:
New features avaiable in latest version of the language(s)/framework(s) you use.
Availability of new components/frameworks/plugins that may potentially improve the product.
Requirement has changes it's direction, existing product wasn't designed to cope with new needs.
With above as prerequisite, I want to take this discussion serious and identify the essence of an upgradable solution for a web application. In the discussion you may talk about any stages of development (initial, early upgrade, incremental upgardes) and cover one of more of the following:
Choice of language(s) for a web application.
Decision for using a framework or not? (Consider the overhead)
Choice of DBMS and its design
Choice of hardware(s) and setups?
Strategy to constant changes in requirements (, which can be a natural of web application)
Strategy/decision toward total redesign
Our company's web solution is on its fourth major generation, having evolved considerably over the past 8 years. The most recent generation introduced a broad variety of constructs to help with exactly this task as it was becoming unwieldy to update the previous generation based on new customer demands. Thus, I spent quite a bit of time in 2009 thinking about exactly this problem.
The single most valuable thing you can do is to employ an Agile approach to building software. In particular, you should maintain an environment in which a new build can be (and is) created daily. While daily builds are only one aspect of Agile, this is the practice that is most important in addressing your question. While this isn't the same thing as upgradeability, per se, it nonetheless introduces a discipline into the process that helps reduce the chance that your code base will become unwieldy (or that you'll become an Architect Astronaut).
As far as frameworks and languages go, there are two primary requirements: that the framework be long-lived and stable and that the environment support a Separation of Concerns. ASP.NET has worked well for me in this regard: it has evolved in a rational manner and without discontinuities that invalidate older code. I use a separate Business Logic Layer to manage SoC but ASP.NET does now support MVC development as well. In contrast, I came to dislike PHP after a few months working with it because it just seemed to encourage messy practices that would endanger future upgrades.
With respect to DBMS selection, any modern RDMS (SQL Server, MySQL, Oracle) would serve you well. Here is the key though: you will need to maintain DDL scripts for managing upgrades. It is just a fact of life. So, how do you make this a tractable process? The single most valuable tool from any third-party developer is my copy of SQL Compare from Red Gate. This process used to be a complete nightmare and a significant drag on my ability to evolve my code until I found this tool. So, the generic recommendation is to use a database for which a tool exists to compare database structures. SQL Server is just very fortunate in this regard.
Hardware is almost a don't care. You can always move to new hardware as long as your development process includes with a reasonable release build process.
Strategy for constant changes in requirements. Again, see Agile. I'd encourage you not to even think of them as "requirements" any more - in the traditional sense of a large document filled with specifications. Agile changes that in important ways. I don't keep a requirements document either except when working on contract for an external, paying customer so that I can be assured of appropriate billing and prevent feature creep. At this point, our internal process is so rapid and fluid that the reports from our feature request/bug management software (FogBugz if you want to know) serves as our documentation when documenting a new release for marketing.
The strategy/decision for total redesign is: don't. If you put a reasonable degree of thought into the process you'll be using, choose mainstream tools, and enforce a Separation of Concerns then nothing short of a complete abandonment of HTTP and RDBMSs should cause a total redesign.
If you are Agile enough that anything can change, you are unlikely to ever be in a position where everything must change.
To get the ball rolling, I'd have thought a language/framework that supports the concept of dependency injection (or Inversion of Control as is seems to be called these days) would be high on the list.
You will find out that RDBMS technology is not easily scalable. All vendors will tell you otherwise yet when you try multiple servers and load-balancing the inherent limitations will show up. Everything else can be beefed up with "bigger iron" and may be more efficient code but Databases cannot be split and distributed easily.
Web applications will hopefully drive the innovation in database technologies and help us break out of the archaic Relational Model mind-set. It is long overdue.
I recommend paying a lot of attention to this weak link right from the start.
There might be applications that are not suited for Core Data - image manipulation programs like Photoshop or Gimp for example. But for applications that are suited for Core Data, say Address Book or iCal, what is the criteria to choose Core Data over a custom model?
I recently started a project where I decided to use Core Data for the first time in a real world application. My application is actually version 2.0 of an older app that uses a custom data model, so I spent a lot of time debating this question. Here are some of the things I asked myself.
The time to learn how Core Data works in a non-trivial application and fixing the little bugs and idiosyncrasies that pop up when you're learning a new technology. This may include a prototype or two, since you don't want to jump into using something like Core Data that will be responsible for such as large chunk of your application.
Whether or not Core Data will solve problems that are hard to address when using a custom data model, for example storing and holding in memory very large sets of data.
Whether or not you want to share code with a platform where Core Data is not available, for instance Cocoa Touch. Along the same lines, if you want the resulting data files to be compatible without having to build a separate exporter.
If learning Core Data will help improve yourself as a programmer, whether its making your more attractive to Mac development shops or just for your own use.
If your data model is simple enough that you don't really need things like undo manager support or relationships, the areas where core data really shines.
If you're using external libraries or other technologies such as Distributed Objects, where you might not want to use NSManagedObject.
Are you, for whatever reason, targeting a Mac OS X version before 10.4 as your minimum requirement? If so, no Core Data for you.
Are you going to allow the user to manually order things in a list? If so, no Core Data for you—it doesn't allow ordered relationships. (Supposedly you can create a numeric “sequence” property that you can order by, but keeping that consistent sounds like a tremendous hassle.)
Are you going to be working with a specific file format as your native format? (For example, TextEdit's native format is RTF.) If not, you won't be using Core Data for on-disk storage, so you may not want to use it at all. (You could, but I'm not sure there are enough other reasons.)
Kick :)
For me the biggest question you need to ask yourself is: Are you going to store critical data in there (user created content) or data that can easily be reproduced (content downloaded from internet). If you have the first (user created data) i would steer away from Core Data ASAP or make sure you have a backup plan in your app.
Once bugs start popping up (and trust me, there are) for instance when trying to migrate your data to a new version of your object model you are stuck, completely stuck! And telling your customer "I am sorry I cannot build a new version of your app, I am waiting on Apple to come up with a fix" will not cut it in the real world. There is no official way of accessing or understandig the underlying structures, so once it goes boom, you are on your own.
Been there done that, not going there again!
my 2 cents