This is great. Seriously. I cut my teeth in the early 2000s writing the type of PHP code that would make your eyes bleed. Global variables everywhere. HTML/PHP/MySQL in the same file. Career-wise I ended up going down a backend/database developer path, so if I do anything with consumer-facing web applications, it's on my free time.
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. Shouldn't I be using a framework? Wouldn't Python or Ruby be a better language to use now? Is it 'cheating' if I just throw these form elements in an HTML table? Shouldn't I be using something more scalable for the backend than a default installation of MySQL 5.1?
And yet, every time I try and address any of the above, it just gets frustrating to me. I have a limited of free time to work on this web application each week. So I want to spend that time actually DOING things with my web application, not just ramping up on learning some stuff so that I can maybe do some things a few weeks from now. This web application is getting a bit of traction with users. I always figured that I would eventually "code myself into a corner," and that making these suboptimal technology stack choices would result in me hitting some local maxima that would bite me in the ass and I'd have to basically rewrite everything.
But after reading this blog post, I feel a lot better about my choices. If this guy can make his web application work with the technology stack he prefers, then so can I.
"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.
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!
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.
(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.
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).
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 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.
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.
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.
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.
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
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.
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.
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.
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)
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."
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.
> 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.
In computing, there is an emphasis on the tools, rather than what you do with them.
It's worth noting that it's not limited to computing either. Countless amateur photographers spend their time discussing hardware, rather than techniques and other aspects that would benefit their craft to a much greater extent.
Personally, as much as I'm fascinated by the tools, I'm much more curious about what you do with them. So I'm always glad when I see someone succeed and create something useful with an odd stack of technologies. It reminds me to focus less on the tools and more on the creation process.
>Countless amateur photographers spend their time discussing hardware, rather than techniques and other aspects that would benefit their craft to a much greater extent.
You see the same thing among firearms enthusiasts. It's fairly common to find people that spend (tens of) thousands of dollars chasing the best gear, but won't spend $2-400 on training from a reputable instructor.
And snowboarders. People spend probably minimum $1k for clothes, boots, board and bindings; plus $70+/day for a lift ticket; but won't spend $50 to go to a group class and actually learn how to do it. And they're dangerous to everyone around them because they can't dismount a goddamn lift without falling down and probably knocking down their neighbors.
And climbers. Nothing like wading through a gibbering horde of prana wearing gumbies topropting with their $350 shiny new 70 meter bicolor ropes first thing in the morning at the crag.
And kayakers. I've lost count of the number of times I've had someone's shiny new boat (closely followed by an expanding slick of random gear) float past me on class III+ runs.
And hikers. Ever see a day hiker doing a mile and a half loop trail wearing a $350 hydration pack, $150 trail shoes clad head to toe in North Face gear?
And blacksmiths. Endless are the rants on why a $800 Beverly throatless shear is infinitely superior to an identical model from Harbor Freight that costs a mere $90.
And car enthusiasts. Ever see a $90,000 sportscar dinking around in traffic on a Saturday afternoon?
See a pattern forming? People (mistakenly or otherwise) attach prestige to the latest expensive gear, regardless of the activity in question.
It's not just the emphasis on tools. Context matters too. I know that pud was trying to make a narrow point, but it's interesting to note that the blog doesn't mention the problem he uses the tools for or the rest of the context. There's a lot of that in the industry as well.
I would extend this to just about anybody who could be considered a "geek". Photography, Programming, Writing, everything. There is so much discussion over tools and process that everyone forgets to actually make stuff.
Which reminds me, I should stop reading HN and get back to work.
I wish more people knew about FreshBooks' rewrite. They had horrible code. And they slowly morphed it into a php-python-ruby mix which is (from my dev friends there) pretty damn good now. It's ok to have a setup or tools that are fucked, but FB would never be able to hold onto developers or iterate quickly on their product if they hadn't sunk at least 9 man-years on the clean up. A million bucks for a slow rewrite is worth the price when it mitigates the risks of a failed from scratch rewrite.
Unlike chess, stones don't move once played. They can only be captured. On a 19x19 board, you have to balance short-term gains with long-term gains. Since there are no left-right or top-bottom orientations, you often have to reimagine where you draw the lines of territory as you play. Sometimes, you can kill your shapes by playing too many stones. Better players can see where things will go, identify "dead shapes," and stop wasting time trying to rescue them. Sometimes you trade off bad moves for bigger gains. Sometimes you simply have to work with mistakes you made in the early game.
This is very much like writing code and getting it to market. You're trying to build something despite disruptive opposition even as the clock winds down.
Ah, but in Go there is the concept of good shape - you can play along similar strategic lines with both good and bad shape, but if you play your stones clumsily (write your code in PHP?), you will be vulnerable to many forcing plays and clever tesuji that may transform the position into an unwinnable one. It could happen during the middle game - bad shape may allow a group to be cut in half or have its eye shape pounded out of it - or in the yose, where you may need to make a very large number of moves to defend very few points (long development cycles to add features to a poorly written product?).
Therefore the analogy of Go justifies spending time making good shape with your code as you go along.
The problems are very challenging, but that shouldn't stop you from thinking about them and then enjoying the enlightenment of the answers after a minute. Very helpful material! Best of luck in your pursuit of a better game
Funny you should mention that. Right after you talked about shapes, I browsed through Sensei's Library and saw that too. Thanks for the recommendation.
For someone who's known of Go but never took the time to learn or play it, that's the best sales pitch for it I've ever heard. Makes it sound like it has the fundamental simplicity of checkers and the strategic complexity of chess. Adding it to my learning list now.
Some weird part of me loves this, and I don't know why.
That said, I'm very confused. The post says these sites are running off of your "awesome" backend:
* http://www.pud.com
* http://adhdinc.com
But those are just pages with links to other services? Furthermore, while some of those services (TinyLetter, FaqMe) do seem to be produced by ADHD, others (Blippy, AdBrite) do not seem to be, though it seems you claim to have participated in them in some way, shape or form.
I don't really care one way or the other, but my real question here is: Which websites in your list are actually running off of the backend described here?
On this stack: TinyLetter.com, FaqMe.com, and many of the other sites listed on pud.com and adhdinc.com. (and more importantly, not-yet-released stuff I'm currently working on).
I co-founded both Blippy and AdBrite but did not have technical roles there, so they have nothing to do with this stack.
Use what you know, use it well, and make a difference.
---
Most techies who have a negative opinion about any technology do it with hearsay and not first hand experience.
For examples, all web languages pretty much do the same stuff, and you'll rarely come across a web app that uses a language in a novel way that actually makes a difference which language you use. They all have their pros and cons, it just depends on what you want to coo / boo over.
To be fair many haven't accessed the tools that may require money to use. Alternatively others might not have had the luxury of free time to learn something on their own. It's not better, or worse, just different. Sadly a lot of devs build wizardry to make their own lives easier and avoid tackling making their users lives easier, and that shouldn't happen in any language.
All that matters is can you deliver a result that works well. If techies spent as much time obsessing over improving their skills and finding way to build valuable solutions than which tools to use, they'd know this.
For those who hold a holier than thou attitude in believing the only way one can correctly create and innovate with a computer (software included) need to be from narrow list of tools/education fields, they forget that smart people can often learn to be great at more than one thing:
"I was lucky to get into computers when it was a very young and idealistic industry. There weren't many degrees offered in computer science, so people in computers were brilliant people from mathematics, physics, music, zoology, whatever. They loved it, and no one was really in it for the money."
(Fortune) Steve Jobs
"Most techies who have a negative opinion about any technology do it with hearsay and not first hand experience."
You'll find that even when you have first hand experience, you'll often be met with "well, you didn't do it right". Or "you need to do XYZ first - no one ever does foobar with XYZ first - are you stupid?". And so on. Even first hand experience isn't enough for some fanboys when you choose to reject their tools/languages.
Lol, good point. It's kind of ironic that geeks who were picked/excluded/ostracized in school turn on each other in their adult lives and become snob/hipsters, instead of breaking the cycle.
Love and power to anyone doing anything good out there with the tools that enable to do them.
As for the fanatics who can't change the topic (to keep bashing) or change their mind.. I hope you can see the forest for the trees one day.
Imagine what it would feel to be supported by a developer of any language and doing the same for others. We should cheer accomplishments, not berate, belittle and attack others without a track record of our own.
When it comes to getting opinions, I learn a little more every day to ignore anyone who is a perfectionist and hasn't accomplished/launched/profited. It's the enemy.
Scaling/rebuilding/whatever you're afraid of is okay when you're growing and profitable. No business built itself in one version.
Remember, In 10 years you might have forgotten about the tools you're so passionate about today.
> It's kind of ironic that geeks who were picked/excluded/ostracized in school turn on each other in their adult lives and become snob/hipsters, instead of breaking the cycle.
" It's kind of ironic that geeks who were picked/excluded/ostracized in school turn on each other in their adult lives and become snob/hipsters, instead of breaking the cycle."
This is more a result of our tribal tendencies which manifest themselves in a number of ways: including xenophobia, racism, nationalism, religious discrimination etc...
> Most techies who have a negative opinion about any technology do it with hearsay and not first hand experience.
I've used PHP. Trust me, it sucks. It's not worthless, you can certainly build successful whatevers with it. But, it will suck. Perhaps in ways you can't even imagine cause you've never learnt a non-sucky language/system.
I don't hang out with a lot of programmers and I guess this is the reason. This "laughing" the op alludes to. This endless discussion of what language or back end is the best. I find it impossible to talk about programming with people who would rather indoctrinate me on the benefits of their chosen language than talk about, say, data structures. It's like arguing about what colour is the best. It's pointless.
So big ups to pud for his post and his peculiar stack. In its own way, it's a very cool and imaginative stack. And it works, which I think is the only thing that matters in the end.
Talking about the differences between, say, assembly language and Ruby is very different than arguing about what color is the best. I guarantee that some projects will be successful if written in one of those languages, and not the other (webapp in assembly? bootloader in Ruby?).
Also, in your view, how is talking about data structures any better than talking about languages? Wouldn't that just be "indoctrinating me on the benefits" of your chosen data structure? If the only thing that matters is that the program works, then why does it matter what kind of balanced binary tree is in use behind the scenes, any more than the language matters?
Tools do matter. Maybe you're not interested in incremental improvements in your productivity as a programmer, but those who are will probably spend time talking about their tools (hopefully balanced by spending even more time actually using them).
I don't think you read me right. There's nothing wrong with debating the pros and cons of a language (or whatever else), but there's a difference between discussing and preaching. I'm always open to a nice chat, but I've got little patience for preachers. That's all I'm saying.
It's hard to understand your point if you change it. Of course no one likes preachers or endless discussions or anything else that's clearly bad: that doesn't have a whole lot to do with programming languages though. If that's all you're saying, it doesn't amount to much.
What you actually wrote (and what this article partially argues) is that the only thing that mattered was that it worked, which is a statement people can disagree over. Working isn't a binary switch that flips when you launch, any discussion of the value of something as complex as a piece of software has a lot of different dimensions. After all, bubble sort "works" too, but you'd be a pretty terrible computer scientist if that was as far as you investigated the issue.
Yeah, I think we actually agree. :) I have known preachers, and you're right that there is a big difference between them and engineers that just want to find the best tool for the job.
I think we was just trying to differentiate between advocating a particular technology versus discussing a fundamental idea. Using the examples that other people have given from hobbies and sports, it's like the inclination to discuss gear instead of the activity itself.
Discussing software tools as a programmer is nothing at all like discussing lenses on a camera. As far as I'm aware, there's no lens out there that can increase your productivity as a photographer by tenfold. Choosing Ruby over assembly language for a webapp could _easily_ increase your productivity by tenfold (probably more like a hundredfold).
Obviously not every software tool discussion is as exaggerated as that, but even if you're arguing Django vs Rails, there really are significant differences that could affect your work in dramatic ways (e.g. one framework has a plugin that would take you a week to write, while the other doesn't).
The assembly vs ruby analogy is indeed a stretch, but I get your point. Still, what you're talking about boils down to objective discussion and that's something I really like. My problem is with those folks who, instead of having sane debates, get all religious with their programming language(s) of choice.
I don't hang out with a lot of programmers and I guess this is the reason. This "laughing" the op alludes to.
Actually, what this means is that you shouldn't hang out with douchbags, programmers or not. As I can guarantee you, there are just many non-techie douchbags as there are techie ones.
It's like arguing about what colour is the best. It's pointless.
I have a theory that people act this way because of evolution.
--------------------
Imagine you live in a tribe of 10 people, and there are 5 different ways the entire tribe can use to hunt animals for food. All 10 people must hunt together, and each of the 5 ways are equally successful.
After an animal is killed, the tribe determines who was most responsible for the kill, and he/she gets to pick and eat the tastiest meat before anyone else. Others' still get to eat, but it doesn't taste as good.
If all 10 hunters are equally skilled, each will get tasty meat 10% of the time regardless of the hunting method. But humans are not all equally skilled. Some can throw spears better than others. Some can run fast. Some can sneak up quietly. Some can climb trees. Some can wrestle a wild bore.
So what happens? Before a hunt, if you're a fast runner, you say "Let's chase after an animal!" If you can climb trees, you say "No, let's drive an animal up a tree, and climb up to kill it!" You push for the option which gives you the best chance eating tasty meat, and do everything you can to stop any other hunting methods.
Things get political. Someone says; "Running after animals is too much work! Lets climb trees instead!" You say; "Bullshit! Climbing up trees is for pussies. Real hunters run after their food! Plus, we have to see your nasty balls every time you climb up!" You support your cause, and do everything you can to demonize and discredit other options.
Through politics, arguments and fights, you might be able to sway the majority opinion of your tribe in your favor. "Yeah, I guess I don't really like climbing trees either; I'm sick of seeing that guys balls too. Let's run instead!" Now, your entire tribe runs for food, and being the fastest runner, you get tasty meat more than 10% of the time.
--------------------
So my theory goes, when you see someone arguing about something pointless like Windows is better than Linux, even though both are pretty good, what they're really trying to do is sway the opinion of the entire world in their direction. If every company dropped Linux in support of Windows, there would be a lot of Linux sys-admins and programmers out of work. Sure, they could learn Windows, just like a slow runner could learn how to run fast, but they would be at a disadvantage compared to seasoned Windows admins.
The same thing happens with programming languages and APIs. These can be very volatile, going from extremely popular and hot, to nobody wants to touch them in a few years.
When you see someone arguing about what color is better, they're using the same algorithm, only it's firing on something seemingly trivial. But is is? Perhaps if you convince enough people that red is better than blue, the next Macbook Pro you want to buy will end up red instead of blue. Unlikely, but possible...
I don't see how evolution has anything to do with your theory.
Furthermore I doubt that the motivation behind arguing about 'pointless' topics is to sway the population to your side so that you can benefit.
Unfortunately, however, I do not have an explanation as to why people may argue over such topics though I suspect that it may be related/due to cognitive dissonance. There is a conflict between what they have concluded and what someone else has concluded. This could be for many different reasons such as different needs, different preferences, or different skills, but on the surface someone else has made a different choice for what seems like a similar task.
I wouldn't consider discussing Ruby vs. Python 'fluff', but either way my comment above was about people arguing passionately, not having an intelectual discussion.
As long as Xeround sticks around and does what they say they can do, I’ll never have to worry about scaling my database
Never heard of that database/company before so I clicked on the link out of curiosity and guess what, their server is down. Not very reassuring for an "infinitely scalable solution".
Didn't knew about them either. Not too worried about the home page having hickups earlier as it isn't their database cloud. But, I'll definitely do some testing around this/these MySQL MySQL cloud service(s). Something I haven't looked at before and sounds too good to be true.
I don't understand what's so difficult about holding the following facts in your head at once:
1. Better tools make you more productive and make larger problems tractable. Using outdated or subpar tools seriously limits your options, especially if you need to compete with professionals. The simpler your problems, the less this matters.
2. It's easy to get sucked in to constantly learning the new language/framework/toolset when you enjoy learning these things, finding the balance between the diminishing returns of trying out new tech and being highly productive is difficult. Welcome to life.
3. Some people on the internet loudly engage in ignorant fanboyism, especially if they see smart people using their new piece of tech and figure they got onto a good idea early.
4. That same fanboyism defends crappy tools because it's human nature to feel that kind of tribal defensiveness when you've invested a lot of time learning and using something, this is especially strong when someone has all or most of their experience with a single tool or set of tools.
Here's an idea: in the real world tools and productivity are tied in a complicated way.
The comments "it doesn't matter what you use, just keep getting things done!" is just as stupid as "stop working on things and upgrade your skillset immediately!".
Since this is aimed more at the commenters than at pud's submission I will say to him: You are impressively productive with that tech stack, it really doesn't look like it would be difficult for you to move to something more powerful than cold fusion at least. You seem like a pragmatic guy who can see the future payoff from that investment. You also look like a young guy who should not be ignoring the kind of commitment to life long learning necessary to compete in this industry.
What sort of traffic do you push through this infrastructure? Micro instances only have ~600MB of memory and I found them to be severely over-sold cpu-wise -- doesn't windows require like ~300MB of RAM to just boot?
And Windows is only a penny more per hour on micro instances (although that is 50% more than Linux) -- but quite a bit more on larger instances should you ever have to scale up: http://aws.amazon.com/ec2/pric...
Re database choice -- http://xeround.com is totally down right now... Thoughts?
I dunno, just seems like a world of hurt should you actually have to scale up -- but presuming you do, perhaps you'd have the funds and/or resources to cover it anyway.
Additionally, How on earth do you hire people to work in this stack?!?
Is that the same pud that did fuckedconpany? It was a hilarious site where people made fun of over valued companies during the first boom. Unfotunately the site eventually became overrun by nazis (not kidding) and had to be shut down.
I've built my product on CFML as well and I can't understand why it doesn't get more love from the developer community. It's a solid, productive language and the only language available in both commercial and open source (free) versions with tremendous support forums on both fronts. I personally use Railo for the CFML engine. Again, very productive and it enables me to get products to an MVP stage quickly.
For those of you that were not around during the dot.com implosion in 2000-2001, pud (the author of this blog post) ran the notorious site http://www.fuckedcompany.com which gave an awesome view into companies that were going down the tubes during that time.
I wonder if some of the laughing isn't so much at you and your stack, but at the laugher's experiences with those (or similar) technologies.
We've all worked with technologies that cause us pain in our development process. Sometimes, the pain becomes so great that we look for, and find, something that we like better. Changing to this new techonology eases said pain, and allows us to be (or at least feel) more productive.
I believe it's possible that some people laugh because they remember when they used one or more of those technologies, and the pain they felt while using it. They laugh and suggest other technologies because they assume you have the same pains they've had, and they'd like to offer you what they consider a better alternative that might ease some of the pains. After all, it worked for them!
It appears that you've had some pains with this stack, but that you've found ways to deal with those pains that don't involve leaving your current technologies. Good for you. You've built successful applications on them. Also good for you. These are, of course, the things that really matter.
> CFML. I really like programming in CFML (a programming language, “ColdFusion Markup Language,” as opposed to ColdFusion, a commercial CFML interpreter made by Adobe). I know it’s not "cool" like Node.js or Clojure or even RoR.
Doctors used to bleed people with leeches to get out the "bad humors". They stopped using that "tool" for a reason. It was a bad tool, and better "tools" came along.
Not only is CFML not cool, it is hard for most people not familiar with CFML to understand [1]. The syntax mixes in with HTML markup in such a way as to make it very difficult to distinguish the two apart. With a syntax highlighter your mind still has a hard time as there isn't enough of a difference to make a subconscious context switch easy. Also, the need to cram logic constructs into HTML/XML-like syntax makes for some screwed up code. My understanding is that you can put the attributes for the tags in any order, and that means that things you'd always expect (in other languages) to appear in a certain order, like conditions for statements, are instead a matter of style [2].
> It’s got an old vibe. Not just because it was the first made-for-web programming language (tho it’s modern & updated frequently), but because whenever I meet other CFML coders, they’re always old dudes.
My experience with CF developers is similar. This is not a good thing. This is nothing like the C and C++ graybeards you occasionally meet and develop immense respect for. These old CF developers are, in my anecdotal experience, the kind people that learned one type of development and stuck with it for a long, long time. They've not really improved their skill sets beyond what was popular practice when they first learned Cold Fusion. These are the kind of people (I kid you not) that think HTML tables are a great way to get your page layout just right.
Why did the OP take an entire blog post to say what could have been posted to Twitter ("you darn kids and your twittin'!")? The whole post boils down to what appears to be proud, willful ignorance.
A lot of "you're a developer, but you really should learn about business" stuff gets posted to HN. This case looks to be turned around and we have a business person doing double-duty as a developer. My advice is to learn something more current, and not because it's cool. More current technology has business value in that it's easier to find people who can work with/on it, and you will be able to find more of those kind of people for longer. The underlying tech will also (usually) be supported for longer, and by a wider range of companies. The reasons are too many to comprehensively list here.
I wasn't laughing at your back-end, by the way. It made me a little sad.
What I find sad is people making judgements based on twelve year old information. Like most languages CFML has evolved.
People writing CFML today use MVC frameworks, use ORM and the cloud. Yes it is still easy for beginners to write bad code, I think that may be more true in ColdFusion than in other languages. But getting started easily can also be a virtue.
You might be surprised but a lot of the ColdFusion community don't have tunnel vision and are familiar with a lot of other languages.
Yet the OP mentions the <cfquery> tag, which is exactly the problem. It's mixing of the presentation (view) with a DB call (something that should be in a model and routed through a controller).
Yes. But people write crappy code in [your preferred language] too. There's nothing inherent in CFML that forces people to write bad or hard-to-understand code.
> OMG can you believe some people still use TABLES???
> Some people write crappy code in CFML.
Yes. But people write crappy code in [your preferred language] too.
No, I said CFML code is universally hard to understand. Even more so for people already familiar with more popular languages.
> OMG can you believe some people still use TABLES???
view source.
That example was given to make a point about dated skill sets. I didn't imply that your Tumblr blog was table based.
Edit:
To InnocentB's point about HN's HTML. Does anyone here think HN's markup is meant at all to be inspirational? My take has always been that pg has priorities, and a layout for HN firmly based on cleaner HTML & CSS isn't high on that list.
CFML is NOT universally hard to understand. I have been programming over 25 years, and use/have used all kinds of languages. CFML is just another tool.
If you don't like tag based language, you can use pure scripting in CFML pages. Also, nothing in CFML requires or even leads ANYONE to use table based layout. I don't know where you got that idea from.
When i first looked at CFML I had distaste for what i saw. The problem is, what i saw was other peoples bad code. Once i really dove in and started writing CFML myself, i found it is like any other language in that, you can write beautiful, clean, easy to understand and modify code.
CFML has a LOT of things built into it that make db backed web development VERY nice, including:
Db queries and transactions as a first class language member.
Pdf generation, ftp access, email sending, graphing, ALL are first class language features, not to mention native use of java libraries.
Don't get me wrong, i see the value in frameworks like ROR. I just think CFML gets a bad rep when it does not deserve it.
Sorry, you do not understand the meaning of "first class". You mean "included in the standard library". First class is as in first class functions, ie you can assign them to variables.
And for a second I was excited by first class transactions.
PG has addressed the issue of HN's markup several times. One of the major advantages of CSS, that sitewide changes can be made in one place doesn't really apply to HN. All the HTML is generated by Arc code which is written in a reasonably DRY style; major changes can be made in a central place.
I like modern markup and layout better than the way things used to be just like almost everyone else, but It's hard to come up with an argument for switching HN to more modern markup. It wouldn't make the site easier for PG to maintain, and it probably wouldn't result in a change to the visual design unless a designer was brought in.
I read pud's comments as essentially the same thing: he has better things to worry about.
However. A lot of the leeway in technology choice you might have as a lone-wolf entrepreneur fly out the window once you grow beyond that. If you have no intention of growing beyond, go nuts. Use whatever makes you happy. If you do want to grow more, then be prepared for a rewrite.
Into: " If you do want to grow more, then be prepared for a rewrite." ... If you're the dude cutting the checks & you think it's well designed, you don't have to redesign just because your dev gets pissy.
Whats so hard to understand the difference between <form> and <cfform>? Everything cold fusion related starts with a <cf... <cfif> If you don't like it, you can also use a <cfscript> tag:
The whole post boils down to what appears to be proud, willful ignorance.
Perhaps, but I kinda liked the contrast to the constant stream of proud, wilful "Clojure/CoffeeScript/CaramelMacciatoScript is the new black" hipster-sounding posts on HN.
For the record, I find the dogma around tables kind of grating at this point. I understand that table-based layouts get complex and it can be difficult to develop an accurate mental model, but the same goes for regular divs and CSS, especially considering all of the hacks necessary for IE to render CSS semi-properly. I don't know of many browsers that struggle with tables.
While I agree that it's a good general rule to use CSS/divs, if something is taking too long, my philosophy is that you should just make it easy on yourself and break out a table, especially if the layout is something obviously tabular visually.
> Why did the OP take an entire blog post to say what could have been posted to Twitter ("you darn kids and your twittin'!")?
How many blog posts couldn't be boiled down into a twitter post? The fact that something can be transformed into a 140-character blurb for teenagers with short attention spans does not mean that it should be.
> The whole post boils down to what appears to be proud, willful ignorance.
You whole comment really comes off as a bit short-sighted at best. The whole point was to share the way he gets stuff done. The fact that you do things a different way does not make his way wrong. Automatically assuming that your way is best is a sign of professional immaturity.
Your comment still comes off as needlessly arrogant. You compared Cold Fusion to leech therapy and stated that CF developers have simply never learned any new technologies. You mentioned the business value of newer tools, but you seem to miss the business value of leveraging existing knowledge and getting stuff done.
C is a lot more archaic than CF, but sometimes it's the right tool for the job. Archaic doesn't mean wrong. I certainly don't want to program in CF, but if someone else does and it works for them, then more power to them. As others mentioned, this is at least a nice counterpoint to the Latest-AwesomeYetUnproven-NoSQL-SemiFunctional-Framework/Language stuff that flies about so much.
Oh, and they still do leech therapy. The humor theory was bunk, but leech therapy can indeed have benefits.
>These are the kind of people (I kid you not) that think HTML tables are a great way to get your page layout just right.
Is there are good replacement for HTML tables yet that works well in all browsers?
I'm talking about for things that actually need to be laid out in a grid, which, in my experience, is many things. Grids are fairly fundamental to layout and design.
Tables are for tabular data. You wouldn't use a spreadsheet to design a web page so by the same token a table is just as unsuitable.
CSS support is a lot better and more consistent across browsers now than it was even just a year ago, and there are CSS 'frameworks' that make grid based design a trivial task without cluttering your page with table markup where it's not required.
There are even plenty HTML5 'frameworks' (or templates if you prefer) that take backwards compatibility and such like into account so you don't have to faff about with all that yourself.
There are situations when a table based layout just works better. Have you ever designed a site that needs to work with right-to-left text (Arabic / Hebrew) as well as English? If you use tables for your layout a simple 'html {direction:rtl}' fixes everything. If you are doing it the "right" way then you have to reverse every float and margin settings from right to left and vice versa. A nightmare to maintain. Clearly the CSS designers did not have that use case in mind.
It's a mystery to me why the standards bodies didn't just take the code for tables and make an copy of it, just using a new name like "grid" or "layout" or something.
Because HTML is for expressing semantics, not presentation. If you want something that displays like a table, but isn't, you can do that with CSS using display: table.
These frameworks all use pixels. If you're developing a mobile app you need percentage based layouts because you must use the entire screen or the experience will suck. Luckily most mobile browsers support flexbox which seems to work relatively well.
who said tables aren't semantic? Tables say "Hey, I'm going to show you some things with a row column relationship now." Some times table is exactly the semantics you need. It shouldn't be your primary and only tool but if your showing a set of numbers collated and sorted by rows and columns then its pretty much semantically a perfect fit.
I see this argument a lot. You're right, there are situations where tables are semantic. But unless otherwise stated, it's fair to assume that someone who's talking about semantic markup knows that semantic markup includes tables, but simply discourages them for 99% of layout purposes.
If by no longer supporting IE6 we can force these companies to finally go with the times, then by all means, no, we should not consider this. We cannot endlessly cater to every outdated technology ever.
Besides, these companies have absolutely zero valid reasons to keep using this crutch - it's severely outdated, a giant gaping security hole and a hindrance to the entire world wide web.
And no, legacy applications built upon IE6 on which some corporations have based their entire internal communication (or other things) are not an argument for supporting IE6, but instead gives us all the more reason to force them to get rid of it.
I recently left ColdFusion development and I've never been happier. IT has been my anecdotal experience that ColdFusion is an old man's game. They seem to look on newfangled things like Object Oriented programming with mistrust. This guy thinks it almost ruined his business.[1] The 'younger' guys who get into OO, seem to look at Java and think it's a good idea to have three layers of abstraction between their controller and their database wrapper that has four methods on it.[2]
I got out of ColdFusion 8 months ago into PHP, which isn't exactly known as being a hotbed of good code. I feel like just a mediocre programmer at the currently company I'm at would be a way-beyond-stellar ColdFusion developer. Of course this is all anecdotal and hearsay, but my experience is in line with yours.
OOP is poorly implemented by many of the old dudes, partly because Adobe hasn't documented it well. When the defacto standard, Ben Forta barely writes a chapter on it, you know almost no one is listening.
These old CF developers are, in my anecdotal experience, the kind people that learned one type of development and stuck with it for a long, long time.
That's basically the majority of developers, in any language.
I'm not going to bother defending the mindset of the author, though I suggest that if you examine concepts like toolset familiarity, code craftsmanship, and zen, you may see that his way is a path to happiness. (and honestly, from what I recall of CF in my college days, I liked it no less than PHP)
As a ColdFusion developer looking for a job in the valley, I also faced all the negativity associated with the language. In fact, I ended up barely mentioning the language on my resume. If the language was renamed to something else and totally re-branded, it would probably gain more respect. Most people still think of the older versions when it was built in C. But since the conversion to Java, it has been able to benefit from a lot of the Java enhancements while still functioning as a duck-typed language.
Another advantage is that, it has a very short learning curve. But like with any tool, it can be used by amateurs to produce amateur looking code. Using a framework (eg. FW/1) encourages better structured code and OOP approaches.
You can meet most of your web needs with ColdFusion and some highly specialized items may be more complicated. But that is the case with just about any language. The only part where I havent found sufficient documentation or user experiences related to scaling applications. That is not to say, it hasn't been done.
Given the relatively high price of Adobe CF (compared to Ruby/PHP etc), it is not really an option that startups (in the Bay area) will consider. There are open-source CFML engines like Railo as the author notes, but unfortunately, it lacks publicity.
If you don't mind working alone, work with whatever you like. If it's important to your business to attract the best talent, you need to use the best tools. I'm leaving my job largely because of tools & tech, and passed on a lucrative offer to pursue a different job with better tech.
I'm not laughing, I run several sites on a similar stack and it all runs very well. I do run Railo though just because it runs circles around the native CF server (and I don't use any of the "high level" stuff Railo doesn't include), and I use mySQL 5.5, but all under Win 2k8 Server. I have dabbled in several other frameworks as well but I simply keep coming back to CF to get things done. Be it personal familiarity or platform flexibility or a combination of both, it's never come up short or failed to perform very well and that's how I judge something to be an acceptable platform.
Not I. I have debated starting up a blog a few times but lack of time is one issue, and I'm also not sure anyone really cares to hear what I have to say :)
I didn't even know CFML was an open standard.
Check out cfwheels.org before you comment. It's a RoR like framework, and from 15 minutes of tutorials - it's actually pretty good. It handles APIs better than Django and deals with AJAX in a smart way.
CFML verbosity and the entangled html is a downer though.
At the end of the day, making stuff work is all that matters. I would never have considered CFML or IIS or Windows as a webserver, but if it makes your stuff work and helps you make stuff work, why would I laugh at it?
The synchronizing with Dropbox is pretty clever. Had never thought of that. Probably some latency issues--it wouldn't suit all cases but definitely would be a simple fix to a few problems I've had in the past.
Do you (the plural you) really trust Dropbox Inc. enough to give them access to all your application files on your servers?
Personally I don't use Dropbox for anything minimally sensitive (basically, anything that I haven't downloaded from the web) without putting it on a Truecrypt container. Maybe I'm just paranoid, though.
I use it for all of my dotfiles. A small script moves them to the ~/Dropbox/bckp/dotfiles and replaces them with a symbolic link. Also for my ~/scripts folder.
It's wonderful to have access to those in a matter of minutes if you are starting with a new machine...
For an alternative method, I do a similar thing but put them all on Github and have a quick script to symlink them to the right place. Easy to set up a new machine in minutes, and I maintain history indefinitely.
I wouldn't laugh, but I am surprised it works. I have abandoned Cold Fusion in the late 90's - it kept hanging up, to the point of someone (me) having to write a program that detected the lockup and proceeded to restart the service. It may have become more reliable over the years, but I wouldn't know. CFML also has several drawbacks as a web programming language - the way it mixes presentation and application logic makes it hard to test properly and reminds me of what is wrong with a lot of PHP and JSP code out there.
I am also surprised someone claims it's faster to work on Windows than it is on a Unix-like OS. Most of the things I do on servers are moving files around, installing/updating packages and occasionally restarting a daemon. For that, clicking and dragging on a remote GUI is much less efficient than issuing equivalent commands in a shell.
I also read IIS progressed a lot since I last had to automate virtual server creation. Again, Apache runs on Windows and spitting (usually rendering from a template and adding custom values) a new config-file and doing a graceful restart appears simpler than right-clicking, form-filling and manually copying settings from one place to another. Windows doesn't even offer the courtesy of select/middle-button operation (unless you are operating IIS from the console).
Like someone else said, unless your infrastructure fails miserably (and CF/Windows failed me long ago) your app won't suck because of the technologies it stands upon. A good idea implemented in CF, PHP or ASP is just as good as a good idea implemented in Django or Rails or Node or Lisp. It's just that it may be harder to evolve it over time, or make it scale, or deploy it in the first place.
I'm little late here but I can't stop but write my response to this.
I know the problem to laugh about code, backend or infrastructure. I know a lot of people are opinionated and if they don't like something you can't stop them firing on you.
I'm very happy for you that you found a stack which works for you HOWEVER this doesn't mean that it works for others. A lot of programming languages, paradigms, frameworks and infrastructures just work for one guy on his greenfield project but while getting bigger things get lot harder and crappy cause it isn't modular enough or no-one understands "the legacy code" ect.
At beginning it seems like you can't run into such problems but after a couple months of development this happens nearly in every project. You learning from these mistakes and get better with every project. There are a lot of things in software development people are talking about but you can only truly understand it when you came to the point where you have this problem people are describing to fix.
For example a lot of my old colleagues are in love with PHP. They get stuff done with it and somehow they get code shipped but they don't go for elegance and having less code smells. They just go for "it works what you want more?".
Software development is not only "it works" it is far more than that! Maintainable code, readable code, performance, architecture, elegance (for example: less readable code which covers the same as before) you name it.
I found my self learning a lot from different languages, paradigms, people and different systems. For example what I love about linux is: I could write a automatic shell script to do anything. With Windows you can't! You just can't write for every step a shell script a lot of things are only available through the GUI. This bad. I don't like that. And I also don't like to run the GUI on a server. You are wasting a lot of resources here.
Typical posts against CFML. "It's old." Well then so is Java, PHP, you name it. Actually, of all of those languages, CFML has the latest iteration (which is the most important stat). Railo and Adobe both have new updates ariving soon. Hey, how bout that JSTL huh? Morbid since the late 90's.
I don't get it. Would anyone argue that you couldn't launch successful sites this way? Tools are made to improve the process and enable new possibilities; that's why use good tools.
You need elastic load balancing for iPhone Apps, do they call your web servers that often? How many users are you dealing with currently? Wondering if my single server in my house will be enough to launch a new web service shortly..the server is currently a quad core dedicated Ubuntu LAMP Server with 2gigs of ram that I built a little over a year ago, currently hosted off of residential cable
Several of my iPhone apps interact with a web service.
As for your situation, my cable company's upstream is so slow that I wouldn't host anything on it. But if yours is fast and you like dealing with your own hardware, go for it. Maybe you'll be the next Rackspace :)
The web page at http://xeround.com/ is currently unavailable. It may be overloaded or down for maintenance.
HTTP Error 503 (Service Unavailable): The server is currently unable to handle the request. This code indicates that this is a temporary condition and that the server will be up again after a delay.
I work in 7-8 languages, was just wondering referring to my post:
- What was your experience with CFML that made you cringe
- Is it possible the same can happen in any language
- What is better, in what way?
Always looking to use better tools if they really get more done with less effort :)
I will admit that my CFML experience is limited to studying it for an interview (that made me not want the job) and learning it well enough to read old source code for a new application based off the old. (The app was MX 7)
My primary complaints were (as everyone) the verbosity - I've never seen a more verbose templating system, which led people to copy and paste all around. While there were some CFCs, those were mostly for tying to java backend. All this could happen in ASP, for example, but CF seemed to make it painful to do the right thing.
Of course it could happen in other languages, but my experience let me to cringe whenever CF was mentioned.
The OP used Microsoft already, so I'd look along those lines for him, even though my professional life is in java (95% javascript/HTML application with minimal templating from JSP)and my current weekend project is in rails. Razor looks like a nifty templating engine in ASP.NET MVC, for example.
Interestingly, I didn't know ECMAscript (aka Javascript) is too verbose for folks out there.
It turns out that CFML has two syntaxes, script and tag.
The tag based html-type that's being discussed here, and and cfscript.
Cfscript is is nearly identical to javascript and based on ECMAscript. Several languages follow ECMAscript.
In a way, if you know HTML and Javascript, any language should be easier to pick up than a language that looks completely different from HTML and Javascript, no?
I thought that the CFML was the tag language and CFscript was considered separate, and this particular project didn't take advantage of CFscript, but looking around, people aren't too keen on the interfaces given to CFscript, even today.
I can speak to a similar adobe product, Flex (and MXML/ActionScript) and at least there, Adobe tried to figure out what would make most sense in MXML, and then the ActionScript interface fell out of that, rather than what made sense for an ActionScript interface. Then, Adobe pointed everyone to the MXML as documentation, rather than having a separate documentation for ActionScript. However, things didn't work exactly the same.
Perhaps life is better in CFland, but Adobe has seemed to have "good enough? Then ship! Our devs will figure out workarounds." in their DNA. Looking at this thread -- http://forums.adobe.com/thread/507720 -- it seems ColdFusion is no exception.
I had the same reaction to CFML. I too run my site on IIS, but I use ASP-JScript, which is similar in syntax to javascript. I haven't used CFML in a decade, I remember it being clunky and limited compared to ASP 3. If you really want to go modern, there is of course dot-Net.
That would be the problem then, that you haven't used CFML in a decade. I would cringe at using 2001 CFML too, just like I would cringe at using 2001 PHP. It's a whole different beast now.
I'm not surprise people would laugh at this back end, it's sort of a who's who list of frow upon technologies, it's amazing how popularity contests are so prevalent in tech ...
For a webapp written and maintained by one person it does not matter what tools you use. Just like it doesn't matter what tools you use to build a doghouse.
Yes. Their main use is for really wimpy applications, or for apps that need occasional bursts of CPU -- the throttling allows bursts up to 2 compute units, but you get very little on average.
this stack is... interesting. but the real problem, i think, with what he's saying, is that it is basically "i refuse to learn anything new that is not tightly bound to what i already know".
it's true that the laughter is unnecessary, and the trends and hype can be obnoxious, but it is somewhat about the excitement of always learning new things and new ways to think.
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. Shouldn't I be using a framework? Wouldn't Python or Ruby be a better language to use now? Is it 'cheating' if I just throw these form elements in an HTML table? Shouldn't I be using something more scalable for the backend than a default installation of MySQL 5.1?
And yet, every time I try and address any of the above, it just gets frustrating to me. I have a limited of free time to work on this web application each week. So I want to spend that time actually DOING things with my web application, not just ramping up on learning some stuff so that I can maybe do some things a few weeks from now. This web application is getting a bit of traction with users. I always figured that I would eventually "code myself into a corner," and that making these suboptimal technology stack choices would result in me hitting some local maxima that would bite me in the ass and I'd have to basically rewrite everything.
But after reading this blog post, I feel a lot better about my choices. If this guy can make his web application work with the technology stack he prefers, then so can I.