Hacker News Reader

"I'm working on such an app now, and right now the fastest way I can get anything done is writing similar code to what I wrote in 2003. It's not quite as bad, but I continually succumb to doubt."

The biggest objective problem this style has is that it affords everything-injection; cross-site scripting attacks, SQL injection, command injection if you're using shell commands, etc. Every time you bash one string together with another one, you run the serious risk of introducing a security attack, and with this style of programming, you basically have to be thinking about every single string concatenation.

Using a framework that will take some of the cognitive load off can be a net gain. It need not be a Glorious Framework, it just needs to be something that makes doing the right thing easier than doing the wrong thing.

Otherwise, most of the rest of the pain will be felt by you, not your customers, so hey, whatever, go nuts. But this is a legitimate objection to this approach. (And a legitimate objection to every framework that fails to make the right thing easier than the wrong thing, which is still a great deal of them.)

What I find interesting about PHP (among many laughably bad things about it) is that one of its key strengths for beginners is the easy mode-switch between scripted and verbatim mode (i.e. <?php and ?>), but all the large software projects whose code I've read used some kind of templating.

I agree with the sentiments around here, though. If the goal is to write software that works and hopefully makes money, do what you know and ignore this year's hot new framework/language. Write readable code in case you need to refactor it later.

What do these things have to do with a framework? PHP's built-in MySQL drivers (MySQLi, PDO, etc) support and encourage prepared statements and parameter binding. PHP's built-in string library supports HTML-encoding output. PHP's built-in filter library supports validating and sanitizing input. Writing apps without some kind of framework might lead to less organized, tighter coupled code, but it doesn't mean you're mashing together strings and ignoring security.

Small nitpick: the customers will feel the pain if their username/password is leaked through SQL injection.

I have respect for people that can deliver, regardless of what they use. The allure of cool tech is strong but tech doesn't make products: people do.

I cannot see what is wrong with your using plain PHP if you can get the job done faster (as long as you avoid things that make exploits easy, such as raw mysql db functions). When the time for a framework comes, you'll know.

Stop worrying about what others think and good luck!

+1 to both of you!

Oops, sorry, I didn't know this was not appropriate, first thread on HN, long time reader.

here's how I learned Python without noticing it:

(I had a background in PHP, JS, C++) 1. Off hours on 2-3 days with dive into python 3. 2. A month later - 'oh let's do this in python!' on google code jam 3. 'python challenge? that's cool' - one night hackathon a month later 4. 'I hate php, I'll do this new web app in django' 5. Two days messing with django 6. Five days and the app was done.

I don't know if I write 'best practice' python or django but it's about x6 less code than in PHP. I can rewrite my app completely in 2 days.

For me, the biggest problem in learning a new technology is finding the balance between cowboy hacking & analysis paralysis.

Story of my summer Except now I have couple hundred of lines of "legacy" PHP that's not being written in Python just yet and considering time constraints won't be. It makes crossover projects hard.

>I don't know if I write 'best practice' python or django but it's about x6 less code than in PHP.

Just curious... Surely you mean django vs php (not zend or some other framework - which _would_ have been the fair comparison.

I think he compared before (plain php) and after (invested time in learning some new technology).

No, the weird thing is I'm comparing Django to Kohana. The app I worked on in PHP was more complex, but one API page was very similar in both apps:

- Kohana: ~200 lines of code. - Django: 15. Seriously.

It's not only a matter of LOCs, it's also that writing code should be enjoyable. Python is, PHP not so.

Delivering version 1 is very different from delivering version 2, 3 4... That's when the real test of engineering is.

Not just because this is what I do, mainly, but it's such an important point that it deserves highlighting. Working software is easy. Working maintainable software is harder.

I think the article is flawed in many ways, but if you define 'working' software as software that works for users in such a way that people actually want to use it, then working software isn't so easy. And getting from nothing to working software is harder than getting from working software to maintainable software. Or at least it's better understood.

Ha, I'd say non maintainable software isn't working. Just matter of time until it's broke or needs updating.

Use what works for you. For me, the main benefit of a framework is scalability of new developers. If you have to bring on someone else to extend & maintain your code, it's incredibly helpful to be able to point them to documentation.

For me, the main benefit of a framework is scalability of new developers.

That's one, and it's a big one.

The other, even bigger benefit is that other people will do things for you. They'll write plugins for you. They'll develop new versions of the framework for you. They'll do crazy experiments in corners of the framework design space ("Hey, can we make Drupal work with a CouchDB back end through a series of proxies?") and report the results in obscure Stack Overflow posts that will get indexed by Google. They'll find and fix bugs and security holes for you. When you ask one of them about some problem in your system, they'll have a fighting chance to give you useful advice -- even if they've never actually seen your system -- because, hey, all Rails apps are kind of alike, and all Drupal sites are kind of alike, and all node.js installations are kind of alike.

The fact that this is the major benefit of using a common framework is also the reason why the poor OP feels so lonely. The whole point of a common framework is to have lots of meetings and rallies and beer bashes and hackathons and IRC channels so that everyone can swap ideas and recruit each other and basically work in a big team. They generate their own buzz, because the buzz is part of the value. But hand-rolled personal systems don't get that kind of buzz, because -- to paraphrase the ever-paraphrasable Tolstoy -- all standard web frameworks are alike, but all nonstandard web frameworks are nonstandard in their own way.

nhashem, wow you really hit the nail on the head. So accurate it's scary. I too, thought I was the only one who put DOING before "ramping up and learning some stuff so that I can maybe do some things a few weeks from now." And of course Pud for the courage to be honest about how he's working.

So many times in startups and new endeavors, getting things out is far more important than doing it "right". It's stinky, but it's a reality. If your checkbook, bills and time say one thing but your code says another, your checkbook/bills/time win - always. And the person who can pump out more working (working, not necessarily pretty/proper code-wise or stack-wise) apps wins (even if they lose, they win, based on odds - more attempts means more possible chances at winning).

Just wanted to add: this is all imo. :)

It's interesting to me that you thought you were the only one who put doing before ...learning, for lack of a better word - from what I can tell, the trendy thing at the moment (besides all the trendy technologies) is to spurn design, best practices, and maintainability in favor of doing things in the stinky, realistic, checkbook and bills friendly manner. At least if you're judging solely based on articles and comments that get upvoted on HN. It's a constant pendulum between "right" and "quick", which makes me think the answer is almost certainly somewhere in the middle. Honestly, it makes me wary of being a customer of startups currently, if everyone is just trying to get to version 1 as quickly as possible without any consideration for the future, so I hope that attitude is not as widely spread as it appears to be.

Really you should only be worried if you're using version 1 apps. I'm a fan of quick prototyping and quick release (in alpha/beta, of course), as long as the team is committed to putting the time in on the back-end. Getting a product out is an important step 1...the real work (and money) is in steps 2-1000.

I'd really, really, really advise you at least check out a framework :) Spend 10 minutes reading the documentation behind CodeIgniter (http://codeigniter.com/) and you'll see that you can have more time to spend developing, e.g., features, as the framework has taken care of the routine and mundane stuff.

As a note, I would recommend Kohana (http://kohanaframework.org/) over CodeIgniter, but if you're pushed for time, you don't want to deal with a sparsely-documented framework ;)

I've worked with Kohana a lot and I really don't like it, besides how skinny it is (oh, and the H in HMVC). Weird thing is the best programmer I know recommended it to me.

Kohana is a little brain-damaged. Good intentions, but it's essentially a PHP5 version of CodeIgniter in most ways that matter. The problem with this is that a PHP5 version of CodeIgniter doesn't leverage the constructs and concepts that make PHP5.3 (which in 2011 is the lowest version of PHP you should be considering) much more pleasant to work with than previous iterations. Kohana, and CI2, are both rather meat-axey frameworks, where the trend is toward elegance.

I'd consider Symfony2 for most applications, or Silex (which is the Symfony2 app kernel, stripped of the majority of the Symfony2 framework) if you like writing the plumbing yourself. Yii is pretty nice, too.

Kohana 3 is not a rewrite of CI. it was written from scratch.

Kohana also has the worst documentation in the world. Seriously. It has very clear comments in its source code, though.

Yes, it's written from scratch--which is why I said "essentially". It's a full rewrite into what is still not very idiomatic PHP5.1, and I can't really recommend using a non-5.3 framework given the improvements in expressivity and flexibility that came with 5.3.

Kohana isn't a CI rewrite since 3.0.0. And yeah, Kohana 3.3 will natively use 5.3 goodies.

I've yet to see any indication that it will use PHP5.3 in an idiomatic way. It still seems like a bolt-on.

(I still wouldn't use it because frankly, I don't think the Kohana developers take security seriously enough, but it'd be a start.)

I can't speak for other frameworks, but I definitely second on Kohana, it's light and gets out of your way when you need, yet affords a lot of the newer best practices. If anything, documentation for v3 is lacking, but the forums are somewhat active and the php code isn't actually that complex. Application structure and the idea of overlays on top of system files is an interesting concept and pretty useful.

Have you heard of the term "confirmation bias" before?

I was like you back in the day, then I tried using one of the new frameworks (it was Django) and I was like why didn't I do this earlier, it would have saved me a bunch of time from all the stuff it does for me and the less writing I have to do.

Have a look at the Yii framework.

My web app mockuptiger is exactly what you say html/jquery/php/mysql

look at wordpress, joomla, drupal

Um, what? For all practical purposes, those apps you mentioned are frameworks. Joomla actually has a pretty firm MVC structure inside, and IIRC Wordpress's codebase has a rep for being hard to work with. Drupal makes no bones about being a framework. These are not good examples to support a "just stick it together" philosophy, if that is indeed your philosophy.

You have to stick the layers together at some point, but you'll still probably be better off keeping the glue out of your "business logic".

That's not a bad strategy. I also believe in "Just get it out and done ASAP and brush it up like heck afterwards". Worry about injection attacks, efficiency issues, scaling after you gain some traction. You can always rewrite later when it becomes an issue.

Can you please list out the applications you've created? I'd like to add them to my "never ever register on these sites" list.

If you're only worrying about injection attacks "...after you gain some traction" or "...when it becomes an issue" you're already too late, and I don't ever want to trust any of my private data with you, ever. This is the 21st century. Scrubbing and validating user input is _trivial_ now, framework or no.

Please, please, please, everyone who reads this, spend a day reading the OWASP guidelines, and _use_ their sample code. This isn't difficult, and it makes your applications a million times more secure _on_ _day_ _one_.

Oh please. I'm not building anything that requires a credit card, or anything sophisticated. When you have literally just a hundred users, YES I will skip paying lots of attention on injection attacks because the chances of that happening is very low. To you techies, it sounds like a huge deal, but the priority in any business to make profit first.

Sorry, but this is bull. If you take any information, even if it's an email and password, data security is either tops on your list or you're abusing your users (even "only a hundred"; one is too many!). There is literally zero middle ground on this: you do it or you shouldn't be building web applications. And given how utterly trivial it is to provide proof against injection attacks in any modern language and toolkit, choosing not to do so because it's "hard" as irresponsible as you can get.

This sort of behavior is why the rest of us get a bad rap.

> Sorry, but this is bull. If you take any information, even if it's an email and password, data security is either tops on your list or you're abusing your users (even "only a hundred"; one is too many!). There is literally zero middle ground on this: you do it or you shouldn't be building web applications

http://blog.moertel.com/articles/2006/12/15/never-store-pass...

Needless to say, almost 5 years have passed and they're still around :) their traffic probably a couple of orders of magnitude higher. I was there when it happened, and yes, probably some Russian hacker or whatnot has my password from there, but that's not such a big deal because reddit doesn't know my name, doesn't have my CC number or any details related to my life.

Now, were this to happen to a company that has a lot more information available about each and every one of us stored in one central place (think Google or FB), then things could get really nasty. And I'm not talking about stupid mistakes like the one from above, I'm talking about MITM attacks orchestrated by (vicious) Governments, or cyber-warfare, or just plain old NSA not having to bother to collect information from a myriad of places anymore, when they can just go directly to the source.

I'm unclear why you replied to me, because you didn't say anything meaningful.

I did not say you couldn't build web applications if you were a jerkass who was cavalier with the security of his users' data. I said you shouldn't.

>I did not say you couldn't build web applications if you were a jerkass who was cavalier with the security of his users' data. I said you shouldn't.

That would have left us without reddit, I don't know about you, but without it the Internet would have been a lot less interesting.

Compromising user data isn't a prerequisite to building something cool. Negligence is still negligence. Drunk drivers make it home without killing anyone more often than not.

Ok Point taken. And lesson learned. I take what I said back. Security is important.

Sure. But if you've built a crap back-end for a content site (that doesn't even ask for emails) and someone manages to inject some alware taht attempts to download crap to your users computer -- then you realise that crappy unprotected php is a really really bad idea. (In my defence - I was very young)

Let this post be a warning to web entrepreneurs everywhere-- if you take shortcuts like this, your business will get burned at some point in the future. Every single thing you've just said is wrong. Every single thing.

First -- "the chances of that happening is very low." Let this be an education; there are automated toolsets that seek out and exploit known vulnerabilities in software across the entire Internet. If you have a public-facing website, you will get attacked. Period. The chances aren't "very low", they are a certainty. There are also toolsets that are used to do much more low-level scans for things like XSS, SQL injection, etc. These are commonly used by security auditors, but are also used by 13 year old kids who want to compromise your site. Again-- the chances aren't "very low", they are a certainty.

Next -- "...but the priority in any business to make profit first." State attorneys general are very quickly drafting personal privacy laws. I believe Massachusetts and Nevada are leading the way here, whereby any personally-identifiable information is _required_ _by_ _law_ to be held to the same rigorous data protection standards as PCI. If your site is breached, you will get sued, and you will lose.

Following OWASP takes maybe an extra day's worth of time out of a developer-- saying that you're just going to ignore it because hey, what's the worst that could happen -- again, I would ask you to list what you're building, so I can avoid it forever.

I'm not going to jump down your throat on this, because everyone is inexperienced at some point, and you can never know everything, so on one hand your attitude of "just ship" is healthy.

That said, one of the things that (hopefully) comes with experience is knowing when and where to cut corners. Basic security practices are one place where you need to bake your understanding into everything you do from a low level, because security is one of the hardest "features" to retrofit. Also because basic security does not have to be hard. Hell, you can make an informed decision not to use SSL on your login page, but it must be just that, informed.

Unlike the language du jour, security principles are something that will apply to all programming you do for the rest of your life. So, though you may decide not to use trendy framework x, y or z today, failing to learn basic security and apply it consistently will slowly turn you from a young developer with bright ideas and a lot of potential, to a middle-aged hack developer with a defensive chip on his shoulder.

Credit cards are only part of the problem. If your site can be hacked, then the hackers can:

1) upload scripts to send unsolicited email, getting your IP address banned.

2) upload scripts to scan the internet for other targets (most common---an SSH scanner)

3) modify the HTML output to leak Google Page Rank to questionable sites, which risks your Google Page Rank.

4) passwords of users, who typically use the same password on other sites.

5) setup an illegal file trading section, hidden from most users (anything from music and films to kiddie porn (saw this first hand, and what once was seen can never be unseen---shudder))

6) IRC clients to control botnets.

I've seen all of these first hand working at several web hosting companies. It's more than just "credit cards."

You're classing injection attacks with scaling and efficiency? I want to believe I've misread.

Most people do, but taking it as a calculated risk rather than ignorance or denial seems more honest. If you have no customers, and the worst case liability is not too bad, then a calculated risk is just that. Not something I would choose, but it is arguably rational in some cases...

Problem is that 'rewrite later' never happens because you're always busy. Setting up safeguards to protect against common attacks is quick enough that it can be done upfront. Efficiency and scaling can usually wait, though figure it out ahead of time if possible.

This. "I'll worry about security when I hit the big time" can only work if you never actually hit the big time.

> Worry about injection attacks (...) after you gain some traction

Stop doing it right now.

There are automated tools that detect injection vulnerabilities and people who will hack you for a dozen e-mail addresses and passwords (and, possibly, control of your server). Sanitizing user input is easy.

While I agree the odds of gaining lots of traction are small, when you do, it hits you very fast. You should at least know the hot spots of your application so you can optimize them easily when possible. I am not telling you to save user registration data on a Cassandra cluster just in case, but employing good algorithms when possible. My apps usually are able to generate JMeter config files that make load testing with real data very painless.

Injection attack should not be an afterthought worry, but just a standard you follow as a matter of fact when you're coding. The funny thing about this all thread is that in ColdFusion you have built in immunity as long as you build your queries using sql parameters. As for the rest - efficiency and scaling are not hard to deal with if you just form the habit to consider them as, again, a matter of fact task to perform.