- The layout does render correctly at 1024x768 (iPad).
- Some of the drop downs do not work when tapped.
- Make the movie detail page URL more SEO friendly (include the title instead of your internal ID).
- Don't force users to download images & titles from a few dozen other movies when looking at the movie detail page.
- Focus on being mobile friendly. I can imagine a site like this being most useful when I see a poster or trailer at the local theater and want to remember it. In that situation, I'm on my phone with a slower connection (or one that is capped).
- You're building a site with lots of utility, not a content site. I'm not sure links to half a dozen social media services will serve your users (along with forcing mobile visitors to download all that JavaScript).
- Movie release dates vary greatly across countries. Even the US, smaller independent films will have slow roll outs over longer periods of time. Some bigger films will premier in NY and LA weeks or months before being released in a wider market. And not all films will be available in all areas. Your site gives no indication of any of this at all.
She's also got a repo called "Kittydar" (Face detection for cats in JavaScript). This is someone who loves her language of choice and is just spinning out some fun projects with it. I think that's great.
Rewriting sed in JavaScript is cool. Even as a one-off, proof of concept, "I did this because I could." I mean, why not? Isn't that what the so-called hacker "ethos" is supposed to be about? She never said her version was better. She never evangelized its use over the traditional *NIX tools.
In the early 1990s, some crazy bastard decided to riff on the Unix kernel. About a decade later, another nut decided to rewrite the encyclopedia, and encouraged people to help him do it. Then another crazy wrote a programming tutorial using bizarre illustrations while eating a lot of chunky bacon. Why not? All three of those projects could have been considered pointless. We already had kernels. We had encyclopedias, and god knows, plenty of programming books.
I have the urge now to follow in Heather's footsteps, waste my own time, and write a version of sed in PHP. Or maybe Perl. And then write a wrapper for it in Applescript. Because, why not?
For the record, JS isn't just "her language of choice". Heather works for Mozilla, and has contributed extensively to Mozilla's JS Engine[1]. So, she knows the language damn well... she literally wrote it.
OK, I'll bite. What follows is devil's advocacy, so be warned.
On the whole, it would be better for the world if you wrote something that provided either novel functionality or improved functionality over the existing code. A poor man's sed in PHP is not really very useful, unless there's some way in which your version is going to be better for users - faster, more reliable, easier to use (though the latter could be achieved by wrapping sed in a nicer interface).
Secondly, the people most likely to use such a program are PHP developers who aren't aware of sed. They would probably be better served by being told how to use sed rather than thinking that they have to use the PHP ghetto version. Knowing that lots of people are using your poor-man's-sed, and even getting kudos from these people, does not mean that you've created something new and awesome.
OK, devil's advocate over. I don't really believe all of that, although there is _some_ truth in it. We should try to stand on the shoulders of giants, and creating a monolithic application which replicates the behaviour of sed, grep and find but in a more tightly-coupled and less reusable package is still behaviour worthy of (mild) criticism in a programmer. If we don't make these criticisms, then in 10 years we'll still be awash with half-assed versions of Smalltalk, or package managers that are no advance on apt or yum, or what-have-you.
As a community this is a huge challenge for us. So much work done by programmers is pointless reinvention of work already done (and improved in countless iterations) by others, and we should lament the fact that reuse is so hard that just rewriting stuff in your favourite language is considered to be the best option.
But what about what is better for you as an individual, as far as creating something for learning purposes or because you find a different type of interface easier to use?
> I have the urge now to follow in Heather's footsteps, waste my own time, and write a version of sed in PHP. Or maybe Perl. And then write a wrapper for it in Applescript. Because, why not?
Wise words my friend :)
At least (if by any chance writing sed in PHP doesn't teach you anything) you can look back and say "I've written sed (in PHP), maybe it didn't come up as clean or as good as the real deal, but at least I have done it".
It's become a full blown CMS and its own platform. Half the media sites out there are running it, or hosting with Wordpress Pro. Then there's a horde of casual bloggers managing their own installs.
Granted, there's movement away from this kind of publishing model(Facebook, Twitter, G+), but as long as Wordpress is still the go to, "set it and forget it" app on $5 webhosts, PHP will not die.
> We have server side JS (Node), Ruby, Python and Java --
Hey now. Let's not forget everyone's first love: Perl. :D
It's still quietly running quite a few big sites out there, and is currently enjoying something of a renaissance with frameworks like Mojolicious & Dancer, not to mention the releases of 5.10-5.16.
Perl does maintain a strong niche but if the Perl 6 announcement in 2000(!) had been that all focus was shifting to web development Perl would today be king of the heap. It was web development that pushed PHP and Ruby into the spotlight over the last decade, and the 2000ish Java focus on web frameworks also helped keep it popular.
I'd say there's life in the old dog yet given that BBC's iPlayer site runs on Catalyst.
On the other hand, Dr Dobbs thinks:
"...Perl continues its long decline. According to Google trends, the number of searches for Perl is 19% of what it was in 2004. Its declining role in open-source communities further cements the perception that it's in an irretrievable tailspin."
The most striking thing is the across the board drop from one age group to the next. That to me is the more interesting story here.
Curious about Survata' methodology. Neither the author nor their website go into a great deal of information about this. (I mostly want to know who crafts the questions, as it's easy to inadvertntly skew survey results).
As an aside, linking to Survata's homepage not just once but three times in a ~600 word post makes this thing, aside from its casual observations, feel like an 'advertorial.'
Survata has a DIY survey creation tool, but we review and suggest wording changes to avoid biased questions. We also advise on how to arrange (and randomize) answer choices to allow us to calculate and compensate for answer biases like always clicking the first or last option.
Responses are gathered on surveywalls across the web, where visitors answer short surveys in exchange for free access to premium content (e.g. ebook or video).
Figures in similar communities were older (Larry released Perl in his early thirties, Guido was pushing forty before Python gained traction). They also didn't come up in the era of YouTube, twitter, and archive.org.
Thirty years ago Ruby-style drama would have played out as drunken rant at a post-conference hotel bar, or a snide comment on Usenet, or on an obscure mailing list. Not quite the same.
The Ruby guys didn't have the benefit of age, experience, or a certain amount of professional obscurity.
Love the idea, the context, and the execution. It's a great project. Not a fan of the name.
Zed Shaw has a well-established series of "Learn $topic the Hard Way" online books, with Addison Wesley publishing a 3rd edition of his "Learn Python the Hard Way" this spring. He is building a brand and a business around this name.
I'd be surprised to learn that "Learn ... the Hard Way" isn't trademarked, but even if it isn't, it strikes me as disingenuous, misleading, and potentially confusing to name your work after his.
As far as I can tell, Mr Shaw has nothing to do with this project, but then the "Learn Linux the Hard Way" name might, to some, imply that he does.
Edited to add: I do not have a dog in this fight, just pointing out a potential conflict.
Actually, my understanding is you can't really trademark titles of things. That's why you'll see books and movies with the same titles and nobody getting sued.
There's also a Perl book that predates my book which I didn't know about, so there's precedent for people to do this already.
Finally, I really don't care so much about the title, I care more about people getting the method right. It looks like this was taken down so I can't comment on how it's written, but my typical beef with these books is they use the title, then they proceed to write a completely different book that doesn't follow the method at all. To me that's just obnoxious arrogance on their part and typical programmer "I can do it better" crap. There's a reason my books are structured the way they are, and just taking the title to pimp a book that isn't even close to the same structure just pisses me off.
But, I haven't seen this book yet so I don't know what it's done.
EDIT: Ok found the google cache, and it looks like this one's doing it right. I officially bless this title in the name of ... like whatever and shit.
IANAL, but I'm pretty sure you can trademark titles. An example is the "X for Dummies[1]" series that has at least threatened to sue people[2].
People currently associate "Learn X the Hard Way" where X is computer related to your lcthw project. If you let other people use it, that distinctiveness will go away and it will likely not be something you could trademark
Also: I'm not an expert, or a lawyer, but it's my understanding that you can't copyright titles, but you can trademark them, or portions of them.
The guys (IDW?) that publish the "For Dummies" book series regularly enforce the trademarks around their name and cover design.
Hollywood often gets around the copyright problem by trademarking some film titles (this is why it's always "Disney's The Lion King" and not just "The Lion King.")
Agreed, it's a great project and I applaud you for undertaking it and pushing it so far. Takes a tremendous amount of work and self-motivation to do something like this.
I read the linked post top to bottom twice and I don't see Zed anywhere giving blanket permission to use his title. He is responding to people who ask him if they can port LPtHW to another language, by saying "here's how to write your own so you don't have to port mine".
You should change the name unless you have contacted Zed directly for permission, IMO.
It's a potential point of conflict, but it's a pretty generic naming convention in my view and I'd be dissapointed to see that Zed has slapped a trademark on it. Even if he is building a brand around the name I don't see why he wouldn't be open to letting some other technical authors in under the same umbrella.
You don't understand how trademarks work. Zed automatically has a trademark on it. The question is whether or not he goes through the trouble of enforcing it. If he doesn't, he gives up the mark. Federally registering a trademark is really only to show the due process of protecting your mark.
Copyright is in the same boat.
Also, this is not nearly a generic enough name for it to be ineligible for trademark. It appears that Zed isn't interested in protecting this mark, but that doesn't mean he wouldn't have a case.
I have a puppy in the fight - I started a ruby tutorial titled "Teach Yourself Ruby the Hard Way", but didn't make it past chapter 1, so when Zed released his book I figured it was only right to let him have the name, and rename mine if I ever get around to completing it (2013 resolution!).
So from that perspective, I can't help but agreee that even if Zed is fine with this project, it's a bad idea. It's an unnecessary muddying of a "brand" that has had a lot of work put into it.
PHPStorm plays nice when any framework. The issue it's going to have is when Frameworks do not clearly document, or when they make bad decisions about things. You can, of course turn off different levels of inspections to account for the project you are working on. However, I've found that for the most part, if PHPStorm is flagging something like "undefined method," it's essentially saying "you are hoping that this works as expected." It's a form of static analysis.
I'm not surprised that an old CodeIgniter project flagged these issues.
As for vi, I use vi every day as well. I switch between that and PHPStorm. It depends on the context that I'm in. Both are wonderful tools. But I can assure you, auto-complete is a basic feature of PHPStorm. It's akin to 'set nu'.
Edit: This comment comes off as a bit snarky. It's not intended to be. I think JetBrains and it's line of products are excellent, and I've only ever had good experiences with them. I wouldn't want my comment to reflect poorly on them.
There is normally a little bit of setup to do in getting it to detect objects, methods, and variables. Normally I have to add some stuff into the libraries section. (Sometimes this doesn't work when there is a lot of indirection.)
It does play nicely with Zend and Silex (and other composer-style frameworks). I'm not sure about Symfony or CodeIgnitor.
I must say I really like PyCharm as a Python IDE. Tricked out vim is just too hard to install onto new machines, etc.
It's not a blog, but a collection of weekly email newsletters.
At the risk of sounding like a shill (because I'm pretty sure Mr Cooper posts to HN), I have to say these are each brilliantly done. There are separate newsletters for JavaScript, Ruby, HTML5, and Dart (but sadly no Python).
Great way to keep up with changes in these areas once a week, and pretty much the only third-party emails I not only look forward to receiving, but actually open and read.
I do! :-) Thanks for the mention, you would be a great shill to hire if I were looking.
With regards to Python, I believe http://www.pythonweekly.com/ was inspired by my newsletters. I don't run it but have seen a few issues. There is also http://pycoders.com/ and I know those guys too. Both have a similar structure and approach to mine. Hopefully I can buy/partner with one of them someday rather than launch my own ;-)
- The layout does render correctly at 1024x768 (iPad).
- Some of the drop downs do not work when tapped.
- Make the movie detail page URL more SEO friendly (include the title instead of your internal ID).
- Don't force users to download images & titles from a few dozen other movies when looking at the movie detail page.
- Focus on being mobile friendly. I can imagine a site like this being most useful when I see a poster or trailer at the local theater and want to remember it. In that situation, I'm on my phone with a slower connection (or one that is capped).
- You're building a site with lots of utility, not a content site. I'm not sure links to half a dozen social media services will serve your users (along with forcing mobile visitors to download all that JavaScript).
- Movie release dates vary greatly across countries. Even the US, smaller independent films will have slow roll outs over longer periods of time. Some bigger films will premier in NY and LA weeks or months before being released in a wider market. And not all films will be available in all areas. Your site gives no indication of any of this at all.