This should be at the top of the article to hush folks like myself who might be curious from the get go why another approach wasn't taken and why the Mac Pros were selected. Thanks for the insight as to the why.
It was something that I struggled with while writing the article -- you don't want to introduce your solution as "well, this sucks in various ways, but keep reading...". It does boil down to viewing things pragmatically though. The Macs present challenges, but by our math, they're worth it relative to the cost of doing something else and the benefits they provide.
And we actually run a lot of them in production, so I've figured out how to do it and not pull my hair out constantly. That's something I'd like to write on as well, but it would be in a different medium. More technical depth, less pretty pictures.
You do want to introduce your solution with "this has problems A, B and C, but we went with it because of X, Y and Z." It becomes much more interesting, because you're explaining not just your solution, but the problem space. Just the solution is usually less interesting than why the solution, even with its downsides, solves your problem.
By the way, thanks for clearly, completely and patiently responding to people in this thread.
Agreed, I didn't want to sugar coat things either. I think there is a bit of time given over to the downsides, but finding the right balance is tricky, and perhaps I erred by focusing too strongly on the "this is awesome!" side of things.
I want to explore the design decisions around the chassis in a follow-up, and we have one interview in the can already with the industrial designer. Hopefully that article will be a little faster to get out; this one was written about 3 months ago.
The other angle that I'd love to explore in a more in-depth article is how we actually do this stuff in production, and what we've learned about it. This would delve more into the ugly OS X stuff that we painted over to get things nice and pretty in production.
Having been on CodeMentor for a few weeks now (as a mentor), I have some mixed feelings on the experience. I was hoping that I'd be talking with folks doing interesting things or helping fledging developers on a solid path. You do get that (and it is wonderful when it happens), however most of what it seems to be is `do my homework for me`, `fix my old jquery site`, and stackoverflow type questions answered in realtime. Overall, it has been a positive experience but just not exactly what I expected. I believe in what they are doing and expect things to improve over time if the brand can be grown.
Lastly, there does seem to be a mindset of `I want a stellar developer to talk with but don't truly value their time` (e.g. the $10 for 15 minutes of their time you mentioned). Not always the case, but it is definitely not common to see freelancing type rates. So, you end up donating your time, which isn't always possible to do from a fiscal standpoint.
- Mission which truly helps people and focuses on the end-user and not simply the bottom line
- Working with extremely smart/talented people, who don't take themselves too seriously
- Robust development practices, to the point you can feel proud of your work and allowed to be the best in your field
- Treats employees as adults and also truly value their work/life balance (i.e. happy employees are good employees)
- Money
I'd take ~40k less a year (e.g. 85k vs 125k) if it meant being truly happy in my career with a company that meets the items on that list.
Rather than giving you a specific laptop, I will give you a strategy I have used for a number of years that has worked well for me. It allows you to have brand new equipment each year for less than what you pay buying a laptop and replacing every 3 to 5 years. I've only tried with Apple products.
- Create an Amazon seller account in which you have absolutely stellar reviews and customer service. A perfect five stars is what you are aiming for, which is pretty easy to accomplish if you try (e.g. with roughly 50 sales over the years, I only have one 4 star review and all others are 5 stars).
- Purchase the Mac product(s) you want.
- Ensure you keep good care of the laptops and also keep the original boxes and accessories.
- When Apple comes out with a new version, immediately buy the new version(s).
- Sell your old version(s) via your Amazon seller account.
Personally, I buy a low-end portable laptop (e.g. 12-inch rMB or 11-inch Air) and also a high-end laptop (e.g. 15-inch rMBP). You will find that the low-end of any product by Apple will retain their value best. However, even purchasing high-end (but non-customized) product is still pretty solid. This advice also works for iOS devices. On the whole, it costs me ~$750 a year to "lease" both the laptops. For example, I recently purchased a new low-end rMB for $1299. Given my seller account, I expect to resale the same laptop for ~$1099 when the new version comes out. So, I get a new rMB laptop each year for ~$200.
You will find certain product lines hold their resale value better. For instance, iPads, 13-inch rMBP, and both Airs hold their value well. On the other hand, iMacs and Mac Pros don't hold their value very well. In the middle you have iPhones, 15-inch rMBPs, and Minis. Customized add-ons (in which you can't go into a store and buy) are a huge no-no with this approach. The depreciation cost is just too high.
Heya, I'm Rocky. I'm an avid open source developer, mentor, and lead developer with over twelve years experience. I'm an FP-oriented JavaScript developer with direct influences from Scala, Haskell, and Clojure. My passions lay in the lower-end of the spectrum, with particular emphasis on machine learning, natural language processing, expert systems, and other forms of artificial intelligence. I'm also a data science practitioner with a heavy background in both frequentist and bayesian statistics.
Currently focusing on freelancing in:
- React/React-Native
- Flux/Reflux/Fluxible/Fluxxor
- Electron
- Unified web, iOS, and desktop solutions
Love the final sentence, and thanks for the fresh viewpoint. On the bullets, we differ in opinion on some (maybe I truly am a stick in the mud):
- React/Flux: It IS super new, I just assumed if a company choose/moved to it and are actively coding with it that they would know the basics of it. Certainly wasn't expecting core contributor knowledge by any means, just that fellow devs have read the docs and avoid plainly stated bad patterns in said documentation.
- Security: There is no reason security needs to slow down a project dramatically, if done right. End-user security should be taken seriously and not be something to be tossed aside because it is "hard". Basics get you a long way.
- CS: Good idea on the premium. Though it is often beyond a simple conversation when the concepts of recursion and basic data structure performance/usage is an exotic topic.
- Devops: Solid points, however I wouldn't say it is anything close to a bankrupt concept. Ansible and Salt for a day or two and you have completely manageable, repeatable, and solid approach to your infrastructure.
We agree on what the biggest concerns are. Oddly, I often see nearly everything missing, those being of the most concern.
Functional JavaScripter seeking React/React Native/Flux work with technically strong and collaborative teams. Twelve years as a developer, served as dev lead for top US trafficked sites, additional background in machine learning/AI, bayesian/frequentist statistics, data science, horizontal scaling, micro service architectures, Scala/Haskell/Clojure, etc. Successful react projects with a couple VC backed startups, wanting more.
A concrete example of how I saved a few hundred thousand dollars over the AWS by building quarter rack colocation setups with SuperMicro servers: https://gist.github.com/rockymadden/5561377
With Ansible, I spend no more than an hour a week, amortized, maintaining both the hardware and administration. I assume nodes for any specific role will fail, I only scale horizontally, I always have redundancy for every role, I stay off disk as long as possible (heya 512GB RAM redis cluster), etc.
I really wish GitHub only counted private repos that have more than one collaborator. If you are like me and have dozens and dozens of smaller repos that only you yourself work on, it makes the GitHub model a non-starter (and I'd love to be GitHub only, rather hosting my own server or using bitbucket).
Simply personal preference. I'd like to use the same supporting tools, UI, zero context switching between products, etc. Funny enough, I use some of the social features (issues/milestones/wiki) for project management, even for my own projects.
While bitbucket have some similar features to github (or vice-versa), the features are not the same. So if you want to use only one interface, and you prefer github for projects with multiple collaborators, bitbucket isn't really much of an alternative. Or, if you prefer bitbucket, but is also professionally involved in a number of projects hosted on github, you're still stuck with two interfaces (this is likely the case for pretty much everyone, as almost everyone will have a dependency of some kind hosted on github, and at one point or other you'll probably want to/have to deal with upstream).
This would be true even if bitbucket was (subjectively) better: assuming one values having one consistent interface more than the "best" interface.
I don't necessarily think github's interface(s) are better than bitbucket (or that either are good, for that matter) -- but I can certainly relate to the desire for having a consistent interface, to lower cognitive overhead.
For me, that's the main argument for using Free/Open solutions, that one can self-host: one can guarantee consistency, which in turn can save time. There'll always be a balance between how much time is needed for managing such solutions, and between stability and stagnation.
All that said, it's hard to deny that github managed to leverage the network effect much more dramatically than either self-hosted CVS, stand-alone bugzilla+wiki or Source Forge managed to do. (The latter probably because they didn't realize what they business model should have been: not ads, but charging for forge-services. Then again, AFAIK github isn't profitable, either, yet?).
Re: Debian -- I see that the notabug.org gogs repo[r] contains a debian-folder, and the package build-depends on gccgo (and gccgo-go, which doesn't appear to be in Debian at all, but is in Ubuntu[g]). My initial attempt to build it under plain Debian 7.0 Wheezy (without gccgo-go, just with a "-d"-override) failed -- but perhaps it works on Ubuntu 14.04.
I don't have any idea about the quality/approach taken wrt Debian packaging, just thought it might be a point of interest.
Yeah. I pay for GitHub micro plan and indeed for my personal libraries I use bitbucket. It got a decent cli so I create the remote repo from my terminal.
I would love to use GitHub more, but it becomes pricey for 20+ repos.
Oddly enough, I have two Dell PowerEdge 1850 servers for anyone interested in the Fort Collins, Colorado area. They have been sitting on a bread rack for a while now and could use a good home.
