"...but choosing to build a MySQL editor into a web development package just furthers my impression that Coda is basically designed for the php crowd."
I'm not sure why that is a problem.
This article by Croft is a pretty good summation of almost all of the negative commentary surrounding both the original version of Coda and the upcoming release of Coda 2. The rest of the article is full of digs at people who work in a way different than what Jeff Croft does. It is incredibly condescending.
The reason why I can't stand reading nerdy tech blogs anymore is because everyone is convinced they are right and the rest of the plebes using antiquated (read: different) technology are morons.
I would argue that there are enough people doing things the way Coda best supports to make the creation and marketing of the software justifiable. Otherwise they probably wouldn't be days away from releasing a major new version they appear to have spent a lot of time, money and thought on.
If there's enough demand for software like Coda shouldn't we all just take a big step back and acknowledge that's ok? There's more than one way to operate as a developer today and maybe we should all leave our thousand word treatises that chastise people for doing things the way they want in our "drafts" folder.
I'm sorry, but if you're a professional web developer you need to stop editing files directly on remote servers. Period. Full stop.
Apologists post in threads like these time and time again, whether the argument is for them using PHP, SVN, or whatever. My reply boils down to this:
Sure, you can construct a home using nothing but straw and mud. And because the house is still standing at the end of the first day, you convince yourself that those are good materials for your next job. But don't kid yourself. Straw and mud are not good, modern tools for construction. You're going to be looked down upon by the rest of your industry that moved on to wood, brick, and cement. Deal with it.
What many critics don't really understand about Coda is that it's not necessarily trying to compete with the Textmates, Sublime Texts or Vims out there. As I've used it for years, I believe this tool is built with front-end developers in mind who primarily work with HTML and CSS amongst others.
Rather, I'd make the argument that Coda is the replacement for Dreamweaver. They have similar feature sets but Coda is less clunky than Dreamweaver has traditionally been.
Coda could become an amazing development tool if they allowed something like Sublime Text's Package Control and extensibility of the plugins from that type of architecture. When I go to other editors like Sublime Text, sometimes I sorely miss a Coda's code hinting, default file browser and GUI FTP client.
Hey, Jeff Croft (author of the article) here. I'm not sure you read the whole thing, or read it very closely, because I agree with what you're saying, and I said so in the piece. There's a market for the product, and I don't begrudge them making it -- it's just not for me. I wish Panic would make a product for me, because they make damn good products. It's like if I needed a pickup truck but loved BMWs. Coda isn't what I need, but I really, really want to like it because I love Panic's stuff so much.
You don't HAVE to edit directly on the server with Coda, but it is an OPTION. You can just as easily work locally/commit and then sync with the dev server.
Also, not everyone works on projects hosted on a vps. ftp/sftp is very much still relevant in the real world.
Diet Coda is not meant to be a replacement for your macbook, that is why it is 10 bucks. Also recreating a virtual local file system with git inside an ios app is probably not worth the effort. I for one welcome the "quick hack" nature of the app. Its not meant to be an ide replacement.
"Much as I love Panic, I’ve never used Coda" then why are you writing a critique on software you have never used?
You do have to edit files directly on the server with Diet Coda, and that's the product I was talking about when I made the point about editing files directly on the server.
And it wasn't a critique of software I've never used, it was an explanation of why it has never appealed to me.
Okay, I wouldn't really call his article a "critique". He's just presenting his thoughts on an app that hasn't even been released, and his points seem valid based on the initial feature list of the app.
Just stop reading the article after this because whatever is said doesn't matter. If you aren't the audience for Coda and have never used it, then you aren't going to want their updates.
"Although Coda 2 looks like it has some great new features...it still feels like it continues this trend of catering to developers from five years ago."
Who says software (most especially code editors) should appeal to every single kind of developer? Look, it may not fit your work flow, but it sure as hell does mine and all of my coworkers. I know I'm not alone on this either.
Steven Frank of Panic, responds to Jeff in the comments:
"There’s no way we could be a perfect fit for everyone’s workflow, so we concentrated on what we perceived to be the most common workflows, and those that would the most generally adaptable."
I had a whole response ready, but it looks like Steven Frank - one of the founders and devs at Panic - replied in the comments and addressed all the issues:
"We edit directly on a server — but not our production server. We have a staging server which is an identical clone of the production server, and also a Subversion working copy. A deployment script syncs everything over to production when it’s ready, which is a separate operation from committing it to the svn repo.
Ever since we shipped Coda 1, we’ve learned that there are as many ways to set up a web development infrastructure as there are web developers. There’s no way we could be a perfect fit for everyone’s workflow, so we concentrated on what we perceived to be the most common workflows, and those that would the most generally adaptable."
I'd suggest that a very significant proportion of devs are of the variety Jeff describes. Panic is a business, and they've identified a market segment to serve and serve very well. It's not their job to encourage developers to improve their workflow.
[+] [-] bjplink|14 years ago|reply
"...but choosing to build a MySQL editor into a web development package just furthers my impression that Coda is basically designed for the php crowd."
I'm not sure why that is a problem.
This article by Croft is a pretty good summation of almost all of the negative commentary surrounding both the original version of Coda and the upcoming release of Coda 2. The rest of the article is full of digs at people who work in a way different than what Jeff Croft does. It is incredibly condescending.
The reason why I can't stand reading nerdy tech blogs anymore is because everyone is convinced they are right and the rest of the plebes using antiquated (read: different) technology are morons.
I would argue that there are enough people doing things the way Coda best supports to make the creation and marketing of the software justifiable. Otherwise they probably wouldn't be days away from releasing a major new version they appear to have spent a lot of time, money and thought on.
If there's enough demand for software like Coda shouldn't we all just take a big step back and acknowledge that's ok? There's more than one way to operate as a developer today and maybe we should all leave our thousand word treatises that chastise people for doing things the way they want in our "drafts" folder.
[+] [-] Pewpewarrows|14 years ago|reply
Apologists post in threads like these time and time again, whether the argument is for them using PHP, SVN, or whatever. My reply boils down to this:
Sure, you can construct a home using nothing but straw and mud. And because the house is still standing at the end of the first day, you convince yourself that those are good materials for your next job. But don't kid yourself. Straw and mud are not good, modern tools for construction. You're going to be looked down upon by the rest of your industry that moved on to wood, brick, and cement. Deal with it.
[+] [-] technojunkie|14 years ago|reply
Rather, I'd make the argument that Coda is the replacement for Dreamweaver. They have similar feature sets but Coda is less clunky than Dreamweaver has traditionally been.
Coda could become an amazing development tool if they allowed something like Sublime Text's Package Control and extensibility of the plugins from that type of architecture. When I go to other editors like Sublime Text, sometimes I sorely miss a Coda's code hinting, default file browser and GUI FTP client.
[+] [-] jcroft|14 years ago|reply
[+] [-] moondev|14 years ago|reply
You don't HAVE to edit directly on the server with Coda, but it is an OPTION. You can just as easily work locally/commit and then sync with the dev server.
Also, not everyone works on projects hosted on a vps. ftp/sftp is very much still relevant in the real world.
Diet Coda is not meant to be a replacement for your macbook, that is why it is 10 bucks. Also recreating a virtual local file system with git inside an ios app is probably not worth the effort. I for one welcome the "quick hack" nature of the app. Its not meant to be an ide replacement.
"Much as I love Panic, I’ve never used Coda" then why are you writing a critique on software you have never used?
[+] [-] jcroft|14 years ago|reply
And it wasn't a critique of software I've never used, it was an explanation of why it has never appealed to me.
[+] [-] asifjamil|14 years ago|reply
[+] [-] Pewpewarrows|14 years ago|reply
Those two things are not mutually exclusive.
[+] [-] mmuro|14 years ago|reply
Just stop reading the article after this because whatever is said doesn't matter. If you aren't the audience for Coda and have never used it, then you aren't going to want their updates.
"Although Coda 2 looks like it has some great new features...it still feels like it continues this trend of catering to developers from five years ago."
Who says software (most especially code editors) should appeal to every single kind of developer? Look, it may not fit your work flow, but it sure as hell does mine and all of my coworkers. I know I'm not alone on this either.
Steven Frank of Panic, responds to Jeff in the comments: "There’s no way we could be a perfect fit for everyone’s workflow, so we concentrated on what we perceived to be the most common workflows, and those that would the most generally adaptable."
Bingo.
[+] [-] jcroft|14 years ago|reply
[+] [-] 54mf|14 years ago|reply
"We edit directly on a server — but not our production server. We have a staging server which is an identical clone of the production server, and also a Subversion working copy. A deployment script syncs everything over to production when it’s ready, which is a separate operation from committing it to the svn repo.
Ever since we shipped Coda 1, we’ve learned that there are as many ways to set up a web development infrastructure as there are web developers. There’s no way we could be a perfect fit for everyone’s workflow, so we concentrated on what we perceived to be the most common workflows, and those that would the most generally adaptable."
http://jeffcroft.com/blog/2012/may/22/on-coda-2-and-diet-cod...
[+] [-] kareemsabri|14 years ago|reply
[+] [-] marban|14 years ago|reply