DanielShir
Rico's Cheatsheets
I've actually specified that a single license is per a single user but can be installed on multiple machines. I've had several users request this.
As a true example here, my parents' house uses a simple computer to automate watering of different places in their garden. Looked the chip up, 32 bit system. So this will definitely stop working on Jan 2038.
This is just the tip of the iceberg. 2038 is going to be a big issue.
It really varied, depended a lot on the culture of the company itself. Some shops do anything their devs want while others simply ignore them and do whatever some exec decided to do.
The that interested me most was finding the reason why. Sometimes it was ridiculously silly.
Programmer's Time part 1
Keep your software design simple, your code simple, your tools simple. Sure, it's nice to use new and shiny tech for your side projects, but real software should be done simply and efficiently.
Simple trumps everything else, but it takes a real master to know how to pull it off. Especially in the context of complicated software requirements.
During my career I've met very few programmers who are capable of doing this well. It's the true art of the profession IMO.
And there's the connection to last.fm :)
I definitely disagree with pretty much everything. The merits of merge commits have already been proven, and using rebases is basically rewriting history. If you want all work done precisely as happened in real life you should always use merge commits. Saved my ass a bunch of times.
Also, when something breaks after a merge, it's super easy to undo and to deal with - "Yo Don, your merge of feature X just broke feature Y. Run some tests".
I just recently moved to a new job where they love the "everything is on master" approach and that is absolutely terrible IMO. Everything is constantly broken, and developers always end up breaking builds and stepping on each others' toes. CI doesn't help in this case either because you always need to wait for some dev to fix the build. Wouldn't it be better to just undo a merge of some feature (i.e. reject the merge) and then let the dev fix that on her own time? Working just on master is just the wrong way of doing anything on a team with more than 2 people.
Nextpeer is the world's leading multiplayer service for game developers. Our SDK allows any game developer to turn her game into a full on multiplayer match in less than a day. We pride ourselves in keeping integration super simple, absorbing much of the pain usually involved in creating multiplayer games.
About the role:
The mobile networking space provides a fantastic blend of problems. We need creative people to help us build a world class solution for the mass market. At Nextpeer you will push the envelope with what is possible with iOS background processing, keeping the product true to our core values of crafting intuitive, beautiful and innovative mobile experiences.
Required skills:
* 2+ years developing in Cocoa/Objective C (or Swift!)
* Solid understanding of iOS SDK, and Interface Builder
* Solid understanding of networking (TCP/UDP), JSON, REST and other similar web services
* Must have a solid understanding of the software development process, including release management
* Ability to support multiple projects at the same time
* Must be able to brainstorm and communicate technological ideas and issues with peers and IT management
* Must be highly collaborative and able to work with different teams
See https://www.nextpeer.com/about/jobs/ for more details.
Note: At the moment we're unable to accommodate remote workers.
Web API Versioning Smackdown (2011)
On undoing, fixing, or removing commits in git
Angel - open health sensor
Detecting HFT strategies
It was along the lines of:
Client - "Aren't you afraid that Pakistani/Indian developers would undercut you and everyone would go there for their apps?"
Me - "If everyone were going to outsource there, I'd have more work fixing that stuff up, not less"
Perhaps you could expand the question/answer section a bit. Since I'm on a laptop it was a bit difficult to read.