As someone who's been to LIV a few times, I can say that entrance alone on most weekend nights (fri/sat) is $100. "Premium" drinks like Patron (how is that premium?) are $25 a glass. Those skyboxes on the second floor (that look down on the dance floor) start at $10,000 minimum. Fortunately, I never had to pay because I had a mutual friend with the owner. LIV is definitely on the top end of South Beach nightlife, but there are other clubs that have similar prices.
$1600 is roughly an 8 night stay in Miami, at a decent hotel. I think this is a great deal for me as I can stay anywhere they are available when I want. I already pay over $2000 for a single bedroom apartment in downtown Fort Lauderdale - and I am stuck here in a lease for a year.
BlueNRGY / Draker Energy - Fort Lauderdale, FL - ONSITE, REMOTE (for the right candidate)
Come work with a small knit group of engineers in a rapidly expanding market - renewable energy. We're primarily looking for a senior Ruby on Rails developer to work on our flagship SaaS product, but would love for you to also be open to hacking on other technologies (NodeJS, Go, Aurelia, etc) as we build out new and exciting products for our industry. We would prefer on-site, but for the the right candidate we will allow remote. Also a plus if you can geek out on data as we are moving towards analytics and machine learning on our rapidly growing dataset.
If you want to find out more or meet for up for a coffee, email me: eugene_alfonso@bluenrgy.com with the subject HN.
It is about your skill set, not your title. I have met architects who were unbelievable coders. And ones who were nightmares. But every good architect that I know was also a good programmer. They might or might not actually spend much time programming, but they clearly could do it.
My understanding of the reason is that a good architect needs to be able to mentally connect every level from abstract architecture down to actual code. If you can't, then you'll eventually absorb ideas that sound good but don't really work in practice. (A random example that I dealt with was someone who didn't understand the latency added by sequential RPC round trips. And that the latency gets worse if you're making the mistake of using XML as your on the wire format...) And the failure of said ideas can always be attributed to programmers having screwed up your brilliant architecture.
For the record, this observation about architects is not original to me. I spent a year at Google, and in interview training we were clearly told that Google does not have a position for a non-coding architect. This is not to say that Google does not have positions for architects. http://research.google.com/pubs/jeff.html certainly wears the architect hat well, and is behind the design of large chunks of fundamental Google infrastructure. See http://static.googleusercontent.com/media/research.google.co... for an example of his showing that skillset off. But they have to code. Which Jeff does. A lot.
Not always, granted, but the format really can matter.
Grabbing a random benchmark, look at http://www.maxondev.com/serialization-performance-comparison.... It is in C#, but every language is going to give similar results. An efficient on the wire format like protocol buffers is a bit faster and a bit smaller than a sane text format like JSON. But XML is several times slower and several times bigger. He didn't test pretty-printing the XML, but that makes it several times slower and bigger still than plain XML.
This adds up sooner than you'd think. For a start there is a noticeable timing difference between an RPC call that fits in one packet and one that has to be split across two.
If you've got an application that spends a sizable portion of its time in serialization/deserialization, it is obvious that the format chosen will affect maximum throughput. (Many distributed applications spend most of their CPU time doing those two things.) It is harder for the format to have a noticeable impact on latency, but it both can and I've seen it happen.
The OP wrote a blanket statement stating if you follow this specific path you become "rusty" and ultimately end up not being able to code. He then states this becomes an issue when architecting solutions.
To me this is clearly non-sense as someone who's followed this path (and know others who have as well). Being an architect allows me to see the big picture and move the organization in the right direction (as we see it), while still being able to get into the trenches with my developers when something arises or help is needed. Granted, this is different for large enterprises but for startups/small/mid sized businesses, yes, us architects still get our hands dirty (or else we're irrelevant).
I said that there is a specific kind of bad candidate to watch out for who generally HAS followed that specific path.
I DID NOT say that ALL people who follow that path will become that kind of bad candidate. Or even most. Just enough that you can't afford to say, "This guy has been programming for 15+ years, is an architect, and sounds smart. I'll skip the programming test."
Imagine you don't swim, yet you consult with an active swimmer, a professional swimmer, and a scientist who studies swimming and they all say you can swim. Do you jump in the deep end?
I wouldn't. And what OP said is absolutely true when it comes to nootropics. Moda should not be taken lightly. Start with the basics and work your way up.
You jump in the deep end and get cramps, you drown.
You jump in the "deep" end with modafinil and you get a headache, a sleepless night, and people call you ugly? Why is that "not to be taken lightly"? People do a lot worse than that casually.
I was heading into the article expecting him to end up with a stay in a psychiatric unit, with long term memory loss or personality disorders, with organ failure or loss of consciousness. 'Drug nightmares' can go really badly.
And if the good effect was moving him a few percent in focus, do "the basics" ... do anything measurable at all?
By future-proof I didn't actually mean forever. It heavily makes use of es6/es7, so it was designed with "forward-thinking" design choices (forward thinking is what I intended when I wrote future proof). Right now it relies on babel, but as es6/es7 gains adoption it'll grow out of requiring it. Similar to Angular 2.0, which is also being developed with a forward thinking mindset.
I used Scalatra on one other project, and I found it to be difficult to deploy. Whether it's true or not, my impression is that Spark is a little simpler to use and deploy than Scalatra. Scalatra is my second choice though.
