What exactly did you dislike about CodeIgniter? For me CodeIgniter is probably what I'd use if I had to go back to making PHP applications so I'd like to hear any reasons you had against it.
CI was built in the PHP4 days, and for that reason it has a lot of cruft left over. For example, there is no autoloader. Also, classes are loaded as singletons, and are assigned to properties of the controller, which I put into the 'magic' category, and isn't compatible with IDE autocomplete features (I'm a VIM user, but it makes things easier for a lot of developers).
Thanks for sharing! I wished more people would share code of projects they are no longer interested in. The educational value ('how did he/she built this') is worth a lot, regardless of the 'quality' of the code. Thank you!
I've open-sourced a number of projects I was intending to keep closed-source, but gave up on.
One of them was SMOKE[1] - simple Python/Flask site with login. The most interesting part is probably the SMF Forum signature rotator[2], which manually parses HTML[3] that is not intended to be machine-readable.
I have the exact same sentiment; I pretty much open source all of my old projects for people to learn from (I taught a small meetup for a while, it was useful to explain both the good and the bad). I add DEFUNCT to the description if they are really old or have a lot of bad practices. Here's the rest: https://github.com/tlhunter
I've spent many an hour staring at somebody else's code. I love it, but so often when I'm in the middle of a project I totally forget about those time's I've seen code that made me go "wow, I should do that."
i've been trying to put unused stuff on my github https://github.com/th0ma5w and i've received great comments, and people thanking me for showing general concepts and such, so that's been really great to hear, especially from crap i just had sitting around at dead ends.
One thing you could do is write a really good invoicing app that works with a decent GAAP accounting system, like LedgerSMB. If the system is ok, and the database underneath is solid, you can do the GAAP stuff without having to write a whole accounting package.
I think at one point we had some LedgerSMB users using SimpleInvoices and importing data into LedgerSMB.
I think the difficulty with invoicing is that it is so heavily tied to everything else one might try to do in a business, from tracking inventory to CRM to financial accounting. This doesn't mean that one can't do this, but the interconnections seem to be key.
Just as a quick look, this thing is riddled w/ potential sql injections..a number of unchecked/unescaped uri controlled variables. In some cases there's validation of numerics w/ +=0, but in many cases (e.g. $sort_col) there's none.
Okay, so coming from a user of CI 2.0 mind you and using integrated smarty templates with it, I would have to say after using even a micro-framework say silex, I could build a much better enterprise application with modern php5.3/5 features than i can with CI. The major problem is it feels really dirty to include/require statements with CI. Also to build re-usable code within the confines of their existing library system you have to build all your constructors with a single $param argument. The models are junk since they are really just a place to store organized function calls. Their database abstraction is an abomination. Generally the only thing good about CI is that you can break up your source into a marginally logical fashion which can it improves maintainability.
Now as for this application being written in Code Igniter? I don't really see it as a problem since it means it will be easier for lesser experienced dev to pick up and run with the ball. In time they will learn it's major deficiencies and they will move on. But i think there is room for improvement, in fact I think this would be a great project to port to another maybe more robust framework and is a good project for learning new framework translations.
I will say however that the author wanting to rewrite a product like this in nodejs is really only going to make something like this more inherently difficult to maintain since javascript code tends to get more complicated than your typical java / php / python app as it grows. Granted you do have js at your finger tips it is still largely un-tested on massive scale for large application development. It however has shown great promise for handling extreme traffic in terms of concurrency, but it handles it mostly by using async libraries which pile everything into queues of some sort some where. So your code is littered with async callbacks everywhere. Anyways.. Not only that, but the biggest problem of all is the inability to intelligently step through your code with some kind of IDE beyond using a browser-base debuger such as webkit inspector or the online IDE cloud 9.
I don't hate nodejs. I just think people are jumping on the band wagon way too quickly for server-side hosting. For websockets it's a great solution, I just don't like seeing it as "the only solution" for some peoples projects. I'd rather see a more hybrid approach.
I'm curious, I remember a posting a while back that you were trying to sell this app through Flippa? Any details of that experience you would mind sharing (nothing but tire kickers, not the right market, buyer fall thru, etc...)?
Long story short, not a single bid. A lot of people would ask some questions, but would seem to ignore the info on the page. I didn't bother paying extra to have them tweet the site on their twitter, since they tweet seemingly hundreds of times a day and nobody seems to listen.
I'm used to selling items on the Envato marketplace, which provides all of the 'advertising' for me. But it seems that with Flippa, there is so much noise and one has to do their own finding of buyers.
I didn't look through the PHP or MySQL code but the front-end has a clean look (from the video), which is more than is expected from most people who take it upon themselves to develop an invoicing system
Thanks! The public facing layout went through three major revisions and the final one is based on 960.gs. The layout of the app is governed by MochaUI, but it is a custom theme.
There was only about 120 users at its peak. I hesitated, was never ready to make it a real money-making business, and therefor didn't really advertise it.
While I was at a startup recently, I did all of my frontend development in Backbone.js, this app would do a lot better in that framework.
Also, the CI framework isn't all that great, I would have certainly used a different framework. Perhaps even Node.js (which is what I'm doing a lot of my development in nowadays).
I also would have looked for a marketer and devoted more time to the project. The market for this kind of product is very crowded, but there is a lot of room for innovation.
I can't believe you hardcoded this for MySQL instead of using PHP's excellent and versatile PDOs, and I can't believe the 10k line count. Gosh. Is "de-engineering" a suitable term here? Thumbs up for open sourcing your work, though.
I built it using CodeIgniter, and wasn't as proficient in PHP as I am now. CI is a beginner framework and doesn't teach a lot of good practices (e.g. it loads external classes as singletons and uses a class loading script developed during the PHP4 days).
Please can you point me to documentation that shows that you can easily switch vendor when using PDO? The PHP docs clearly state database abstraction isn't purpose of PDO. The purpose of PDO is to abstract access to a database.
In this sense, wouldn't it have been better to either recommend that he should have used a DBA library? Or even recommend that he used PDO in place of CodeIgniter's own DB access library?
The OP's experience aside, I think you're also missing that this was written on top of CodeIgniter. From my own experience and learning, CodeIgniter isn't really the best tool for writing larger applications. It's architecture isn't so great and is largely a remanent of the past. To end a rant about CodeIgniter short, it seems more natural to write namespaced procedures using classes rather than taking full advantage of objects and OO (again, probably due to it being largely a PHP4 framework).
No I'm serious here, renownedmedia. Don't disregard my rant with a silly downvote, but do instead indulge yourself in the PDO methods instead of painting yourself and your projects into corners: http://php.net/manual/en/book.pdo.php
[+] [-] swang|13 years ago|reply
[+] [-] renownedmedia|13 years ago|reply
//CI Class Load Example:
$this->load->library('example'); $this->example->something();
//Raw PHP Class Load Example:
$this->example = new Example(); $this->example->something();
As you can see, the latter is a little more obvious about what is going on.
[+] [-] BjornW|13 years ago|reply
[+] [-] TazeTSchnitzel|13 years ago|reply
One of them was SMOKE[1] - simple Python/Flask site with login. The most interesting part is probably the SMF Forum signature rotator[2], which manually parses HTML[3] that is not intended to be machine-readable.
[1]https://github.com/TazeTSchnitzel/SMOKE
[2]https://github.com/TazeTSchnitzel/SMOKE/blob/master/smoke/sm...
[3]https://github.com/TazeTSchnitzel/SMOKE/blob/master/smoke/sm...
[+] [-] renownedmedia|13 years ago|reply
[+] [-] will_work4tears|13 years ago|reply
Am I doing something wrong? Notes or something?
[+] [-] th0ma5|13 years ago|reply
[+] [-] jumby|13 years ago|reply
[+] [-] einhverfr|13 years ago|reply
One thing you could do is write a really good invoicing app that works with a decent GAAP accounting system, like LedgerSMB. If the system is ok, and the database underneath is solid, you can do the GAAP stuff without having to write a whole accounting package.
[+] [-] renownedmedia|13 years ago|reply
[+] [-] justinkelly|13 years ago|reply
the web based invoicing market is extremely crowded and very hard to complete against the likes of freshbooks.com
though i went the opposite route to you and its working $ for me
created the open source app http://simpleinvoices.org first, got large user based, then offered premium hosting at http://smarterinvoices.com
[+] [-] einhverfr|13 years ago|reply
I think the difficulty with invoicing is that it is so heavily tied to everything else one might try to do in a business, from tracking inventory to CRM to financial accounting. This doesn't mean that one can't do this, but the interconnections seem to be key.
[+] [-] mmmooo|13 years ago|reply
[+] [-] renownedmedia|13 years ago|reply
If I'm wrong, please do let me know!
[+] [-] jumby|13 years ago|reply
[+] [-] notJim|13 years ago|reply
[+] [-] obituary_latte|13 years ago|reply
Tried using it recently and it actually was quite nice despite the lack of docs and other various hiccups.
At any rate, thanks for putting it out.
[+] [-] renownedmedia|13 years ago|reply
[+] [-] krob|13 years ago|reply
Now as for this application being written in Code Igniter? I don't really see it as a problem since it means it will be easier for lesser experienced dev to pick up and run with the ball. In time they will learn it's major deficiencies and they will move on. But i think there is room for improvement, in fact I think this would be a great project to port to another maybe more robust framework and is a good project for learning new framework translations.
I will say however that the author wanting to rewrite a product like this in nodejs is really only going to make something like this more inherently difficult to maintain since javascript code tends to get more complicated than your typical java / php / python app as it grows. Granted you do have js at your finger tips it is still largely un-tested on massive scale for large application development. It however has shown great promise for handling extreme traffic in terms of concurrency, but it handles it mostly by using async libraries which pile everything into queues of some sort some where. So your code is littered with async callbacks everywhere. Anyways.. Not only that, but the biggest problem of all is the inability to intelligently step through your code with some kind of IDE beyond using a browser-base debuger such as webkit inspector or the online IDE cloud 9.
I don't hate nodejs. I just think people are jumping on the band wagon way too quickly for server-side hosting. For websockets it's a great solution, I just don't like seeing it as "the only solution" for some peoples projects. I'd rather see a more hybrid approach.
[+] [-] jbigelow76|13 years ago|reply
[+] [-] renownedmedia|13 years ago|reply
I'm used to selling items on the Envato marketplace, which provides all of the 'advertising' for me. But it seems that with Flippa, there is so much noise and one has to do their own finding of buyers.
[+] [-] danso|13 years ago|reply
[+] [-] renownedmedia|13 years ago|reply
[+] [-] manelvf|13 years ago|reply
[+] [-] renownedmedia|13 years ago|reply
[+] [-] PleaseBeSerious|13 years ago|reply
[+] [-] renownedmedia|13 years ago|reply
Also, the CI framework isn't all that great, I would have certainly used a different framework. Perhaps even Node.js (which is what I'm doing a lot of my development in nowadays).
I also would have looked for a marketer and devoted more time to the project. The market for this kind of product is very crowded, but there is a lot of room for innovation.
[+] [-] pdufour|13 years ago|reply
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] hackermom|13 years ago|reply
[deleted]
[+] [-] BadLogInMyAss|13 years ago|reply
[deleted]
[+] [-] markhuus|13 years ago|reply
[+] [-] sandollars|13 years ago|reply
Make a pull request, sir.
[+] [-] renownedmedia|13 years ago|reply
Here is the suggested CI method for executing database queries: http://codeigniter.com/user_guide/database/examples.html
Nowadays, I prefer (PHP) frameworks with real autoloaders and better OOP usage (like Zend or Kohana).
[+] [-] jwdunne|13 years ago|reply
http://www.php.net/manual/en/intro.pdo.php
In this sense, wouldn't it have been better to either recommend that he should have used a DBA library? Or even recommend that he used PDO in place of CodeIgniter's own DB access library?
The OP's experience aside, I think you're also missing that this was written on top of CodeIgniter. From my own experience and learning, CodeIgniter isn't really the best tool for writing larger applications. It's architecture isn't so great and is largely a remanent of the past. To end a rant about CodeIgniter short, it seems more natural to write namespaced procedures using classes rather than taking full advantage of objects and OO (again, probably due to it being largely a PHP4 framework).
[+] [-] tonywebster|13 years ago|reply
[+] [-] ericingram|13 years ago|reply
Plus, I really disagree with his comment.
[+] [-] markhuus|13 years ago|reply