ipmb

Salt can configure Windows machines, but you need to have the master running on *nix iirc.

If it's a concern, just lock it up behind iptables. Only let your master talk to your minions and your minions can only talk to your master.

Pycoder's Weekly: http://pycoders.com/ Python Weekly: http://www.pythonweekly.com/

...and a shameless plug for my Django bi-weekly

Django Round-up: http://eepurl.com/yZh21 (Archive: http://us2.campaign-archive1.com/home/?u=24fce4628ba1d5814de...)

The Django ecosystem is almost entirely made up of BSD/MIT licensed software. My guess is that licensing this as LGPL is going to hurt its adoption.

Jacob Kaplan-Moss has a good talk on licensing here, http://www.youtube.com/watch?v=vhuF0oalOi8

Some further explanation on how we typically manage our settings files, http://lincolnloop.com/blog/2013/feb/15/django-settings-pari...

The environ trick is nice, and while it makes it harder to shoot yourself in the foot, it doesn't prevent it.

Our work is still primarily client based at Lincoln Loop and we share many of the same principles that GitHub does. Keeping track of billable hours is how we get paid, but our people get to choose when, where, and how many hours they will bill. We've written a little about it here: http://lincolnloop.com/blog/categories/business/

Thanks for the feedback! To address some of your concerns: We're just getting started, so we'll have more videos as time goes on. The videos are highly specialized and take 30-40 hours to research/record/edit, so we felt the price was fair despite being on the high end of what others offer.

If the price is holding you (or anyone else) back, we're happy to refund your money if you don't find them worthwhile after watching (we'll have a similar guarantee on the site shortly).

Sure! I moved from my family from the States to an expat beach community last year. Being jetset with a family of 4 is expensive and not how I wanted to raise my kids, so we just settled down here. Maybe we'll move again next year, maybe not. The experience has been incredible and I'd do it again in a heart beat. Get in touch, I'd be happy to provide more advice/encouragement.

Not as well-known as some of the other examples, but our company, Lincoln Loop (http://lincolnloop.com), is successful and fully virtual.

I'm in the same boat. I whole-heartedly agree that production secret keys, passwords, etc. shouldn't be checked into version control as plain-text.

Even if you use environment variables, you need them stored somewhere (a secrets.py file, a .env file, a upstart script) so they get onto the machine at startup. At the moment we're kicking around GPG encrypting the data and only decrypting it on the machines that need it.

Thanks for the feedback! I filed a couple of issues to address this:

* https://github.com/lincolnloop/django-best-practices/issues/... * https://github.com/lincolnloop/django-best-practices/issues/...

If you think of any more, feel free to file your own.

Yeah, a lot of this is personal preference and obviously, there's a million ways to do it. Our perspective is that manage.py is a script (you never import it as a Python module) so we bump it out and install to your path using setup.py.

If you think of anything, please file an issue https://github.com/lincolnloop/django-best-practices/issues. It's written for the novice-intermediate audience which can sometimes be hard to do when you've been working in it daily for years.

Previous discussion http://news.ycombinator.com/item?id=1962051

What makes you think this was an intentional decision on the developer's part?

He also draws parallels between skateboarding to open source hacking at about 12:45.

The difficulty in a consulting company is that (unlike a SaaS company) there is typically a 1:1 ratio between hours worked and money earned.

Our company does many of the same things, but in the end, we're still tied to the billable hour. I talked about it briefly here: http://lincolnloop.com/blog/2012/may/31/lincoln-loop-everyon...

no

We make our workplace and compensation such that nobody would want to leave. We have almost no turnover.

The only reason you leave is because you think you could do better or make more money. As it stands, people here would rather see Lincoln Loop do better and make more money (which directly benefits them) than try to start their own company.

Everybody sets their own pay, so I don't think we run the same risk.

We felt the same pain and it's why we built Ginger (https://gingerhq.com).

It isn't a project management tool (lots of good ones already exist), but it is a great discussion tool. Our remote team is closer together because of it.

If you try it out, we'd love to hear your thoughts, feedback@gingerhq.com.

At Lincoln Loop, our day-to-day chatter happens in IRC and occasionally Skype.

Any important discussions happen in Ginger (https://gingerhq.com) so people can participate asynchronously (disclaimer: its a product we built).

Once a week we have an optional staff meeting that happens in Google Hangout.

For the tech side, we rely heavily on GitHub and sometimes Pivotal Tracker.

The client passes a unique key with a short TTL to the Node.js server that maps them to the proper user and teams for the duration of their session.

AFAIK it was released after we settled on Node.js.

As the product evolved, the real-time needs (surprisingly) became less than we originally expected. I think this will change as we continue to evolve.

That being said, after the initial page load, almost everything happens without a page refresh or full page load. You see new messages (with favicon notification), votes, unread counts, etc. all in real-time. I think Ginger would feel a lot klunkier without the real-time bits.

Not much more than a cursory look. It sounds like they aim to solve some of the technical challenges we encountered though.

Thanks Frank! I certainly can't take the credit though. Almost everyone on our team (http://lincolnloop.com/about/) has committed to the project repo.

Yeah, I think you've got it.

1. Initial page load dumps in as much data as possible to get things started.

2. All writes go through the Django API (we just look for a success/fail response).

3. All new/real-time data gets pushed to the client via socket.io. This includes data that you yourself created.

#1 is kind of a given, but #2 & #3 are more personal preference/app-specific I think.

We could have done #2 through socket.io, but as noted in the post, Python is our primary language and we wanted to push as much of the logic to it as we could.

At first we had content creators reading responses from the API with all other team members getting their updates from socket.io. This was problematic because creators would get content twice (once over the update channel for the team and once from the API). It resulted in some strange race conditions and a lot of "have I already received this message?" code. In the end, it was easiest for us to just always defer to the data from the socket (which was faster as well).