Not necessarily. Using a 64-bit system and think you're safe? But what if the binary you're running has been compiled for a 32-bit system? What if this is a cloud service you're not even aware of?
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.
Aren't you afraid of radiation at all? I've used this app for a few months, but actually stopped because I didn't like having the device so close to my head for such a long period of time.
Been doing software for 20 years now, and I think the best advice would be to keep things simple.
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.
That's absolutely right.
I haven't disclosed vulnerabilities for several websites because of this exact reason. If there's no bug bounty program, then you're liable and can be criminally prosecuted (and I know cases where the person was sued in civil court as well).
I'm usually a silent reader of HN, but I can't help myself.
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.
As a founder who's been through a liquidation event, I have to say that stock options are a terrible way to reward employees. The tax issues alone (not to mention all the other stuff mentioned in this thread) are a huge pain for most ordinary people. The only reason companies use this is that there's no better alternative... Anyone ever encounter some other financial instrument that's possible to use in this situation?
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