Hacker News Reader

Comment by zalew | Hacker News Reader

chef, vagrant, ubuntu, apt-get, pip, virtualenv, heroku, ssh.. oh there it is, sth about learning django. I'm saying it not to diss your work, but don't you think setting up a linux env on a vm and signing up to heroku shouldn't be the point of a django tutorial? point explained in another discussion about zed's approach to writing 'learn x the hard way' https://news.ycombinator.com/item?id=4961593

View on HN

One of the thing I usually find hardest about trying out any new web-stack is not necessarily writing the code but wrangling with all the ecosystem BS around it.

It's nice for a tutorial to acknowledge this and give you a VM to play around with.

Yes this is hard. In Django especially, not very easy for beginners.

But put it at the end of the tutorial, not at the beginning

Come on guys, they're doing the tutorial to learn Django, not "all the things around it" (which are important, but it is not Django).

This is true, but you need to do battle with "all the things around it" in order to get the thing to work properly in the first place.

I agree that to learn a language you should not focus on "operational" stuff, but once you get into web frameworks that line can get a little blurry.

"3. Make it work for Windows, OSX, and Linux if you can."

This is the reason the VM was introduced. So that no matter what OS the user is running, they can follow along without having to go search for ways to get all this setup and running. The setup is very minimal thanks to Chef and Vagrant.

Kenneth is trying to teach best practices and tools to use. He also explained in the beginning of the video that you should be comfortable with a terminal and text editor that you like. This shouldn't be your first time looking at a terminal.

Heroku is a simple way to get your project out to the public and it's free. Nothing inspired me more as a developer than having others look at my work. I think it adds a little bit of excitement to be able to show your work to others almost immediately. Even if it's something small, it's still something to "show off" and feel good about.

I feel like that reasoning should be outlined in the tutorial. As a newbie, it seems like a pain to get django running if I have to set up a VM just to do it, and the author provides little explanation.

Coming from rails, its weird to me that he seems to emphasize their 'gem install' equivalent over their bundler equivalent.

Otherwise, a great tutorial.

That's because there isn't really a good "bundler equivalent" that I know of. That was one of the more frustrating parts of Python work for me. Virtualenv is kind of a hybrid between gem and bundler, and it works, but it's nowhere near as elegant.

The jobs are divided a bit differently but the combo of gem/rvm/bundler is matched quite nicely by pip and virtualenv (with virtualenvwrapper adding some nice conveniences)

This article covers some of the equivalent jobs using Ruby and Python:

http://gillesfabio.com/blog/2011/03/01/rvm-for-pythonistas-v...

The article misses covering the freeze command in pip which is great for generating requirements.txt files:

pip freeze > requirements.txt

Covered in detail here: http://www.pip-installer.org/en/latest/requirements.html

Requirements.txt is the gemlock equivalent then?

Gemlock sounds more like Yolk:

http://pypi.python.org/pypi/yolk/0.4.3

I actually think setting up those tools in the tutorial video is great. It's nice to see how a real django dev builds a production app. This stuff is rarely covered in other more simplified tutorials.

Perhaps a better title for the series would be "Getting Started with Django in the Real World"

Because in the real world, you need to know things like chef, vagrant, ubuntu, apt-get, pip, virtualenv, heroku, ssh... if you want to do anything beyond building a demo app that only runs locally. I use all this stuff every day and I'm looking forward to going through this tutorial.

I'm also quite excited about the prebuilt VM that targets Heroku as my colleagues and I were just about to do this ourselves to retool our deploy process. This'll be an awesome start, thanks!

I've built plenty of very real Django apps without any of these (except ssh). Heroku's not the only platofrm, Ubuntu's not the only OS. Neither are even significantly mainstream in the industry.

This tutorial is so myopic. It reads more like a recipe from a beginner's cookbook than anything else.

I've also built plenty of Django projects without a lot of the mentioned utilities, but that doesn't make them any less useful or recommended. I'm certain the developer knows that Ubuntu isn't the only OS and Heroku isn't the only deployment platform. I'd argue against the mainstream statement. Ubuntu is one of the more popular server distros used. Do you expect someone to cover every possible platform and PaaS provider?

What Kenneth is offering is obviously a guide with recommendations and not requiring you to use them for your projects. It's ultimately up to the developer to decide what to use.

I became a much better developer after I tried to port my Django apps to dotCloud and Heroku, using these PaaS forced me to really learn how to use git, virtualenv and pip.

Chef and vagrant are going a long way towards giving me most of the things I love about Heroku and dotCloud but with more control.

I actually think it's quite nice to supply a Vagrant VM (or at least the definition and cookbook) to get someone started quickly.

I'm only confused at why installing pip/python isn't done via the chef file also. If you ever wanted to destroy the VM instance it'd be nice to not have to re-run any setup.

This tutorial doesn't require you to learn chef or use it directly in anyway so I don't think that's fair to include on the list of complaints.

I started learning Python/Django 4 months ago. At first I avoided deployment but when I got around to it, I easily spent over 1/3 of the last 4 months messing with most of the things outlined in the first lesson - and in fact I ended up making a VM (with VMware and dotcloud in my case) to ease setup pain for future projects. This one lesson alone would have saved me at least 2 weeks.

I don't see why giving the user more info on how to handle a full project since the beginning is a bad thing, the django part will certainly be independent of the rest of the tools.

it's not really the same thing. the learn the hard way method is fine for learning something like python or ruby (or whatever language), but not extendable for something like django where you have to set up the db and set the method for deployment. All the other stuff is the teachers way of saying here is the best way to get this set up no matter what your os and what state of disrepair it is in because of all the other tutorials you might have done.

On a tangent, it really goes to show how heavy django development really is. Almost frustratingly so. I keep hearing that it's the web framework for developers on a deadline (it being developed by and for journalists from the get-go), but holy smokes does it take a while to get your stack set up. and for me, I've never done it all in one shot. Whenever I decide to sitdown and take a crack at django, I end up debugging the configuration for about a day and a half.

Reply on news.ycombinator.com