crashoverdrive

Joined 14 years ago

Karma
213
Submissions
43
Member since
Jul 22
View on Hacker News

Recent submissions

Comment · 8 years ago
> "people with real adhd can't get high from stims", but i suspect that some of this is just that people want to distance their legitimate use from those tweakers over there.

I don't know if "High" is the right word. I've accidentally taken too much, and it makes me super impatient, which makes me kind of an asshole. I've also taken WAY too much on accident, and it just made me paranoid and think my heart was beating out of my chest.

I will say, being on a normal amount is kind of the best kind of high. Living with ADHD is like drowning, like you have these short moments of coming up for air and being productive, but quickly become distracted for everything else.

Being on the right amount, is like someone finally shut all the extra TVs off in the back of my brain. Like there's no challenge in determining the priority of what needs to be done. I feel human, not anxious, not depressed by my inability to remember where I put my keys 30 seconds ago. and thus, more productive.

Now I don't claim that my experience with ADHD is like another's, but this is my experience.

Comment · 8 years ago
I’m sorry you did this. Someday, you’ll be sorry you did this. Historically speaking, there is a correction every year. Corrections last on average no more than 54 days. After a correction, the stock market will go back to rising. Timing the market is near impossible, but leaving the market is just asking to lose money. With some reading and some fear management, you could be extremely successful in the stock market. But you have to learn to buy and hold.
Comment · 11 years ago
Okay then. Let's play the "hard nosed technical justification" for this new architectural mold. Specifically pointed at your issues.

> The serialization/deserialization layer adds potential for bugs.

Adding an agreed upon layer that aligns with clean architecture[0) will actually produce less bugs both upstream and downstream. (This is why contract apis are important) and are actually more valuable than monolithic systems where there is a sincere lack of data and state guarantees. (clean understanding vs black box mentality)

> The massively increased number of services all need constant monitoring.

It's the same amount of monitoring. It's just horizontally scaled and is actually easier to pinpoint issues. This also allows you the ability to change or create circuit breakers to fail over when issues targeting specific are found. (see slides 134-150 of Sam Newman's principles of microservices [1])

> The massively multiplied error conditions (what happens when service 37 talks to 39 and 39 times out?) need to be accounted for and those edge cases must be ironed out.

They should have been "ironed out" well before this point to begin with. If the application fails due to infrastructure issues, it is actually an application design failure that should have been identified and resolved previously via TDD and failure state testing. Graceful failure is always desirable, and having a legacy monolithic application does not prevent infrastructure/connectivity failures. (for reference, check out Martin Fowler's "The 12 Factor App" [2])

> You get fuck all except migraines caused by the brittleness of your app.

What it sounds like you're saying is:

"Building a monolithic app allows you to crutch bad behavior and poor design without having to understand the realities of software. You can ignore scalability, clean architecture, concurrency, data modeling and graceful failures."

I can understand how moving to a microservice could seem very painful and have a brittle result without the depth of understanding these realities. This is specifically why I noted it is a required paradigm shift for many developers.

For more inspired reading, you may want to checkout Gilt's discussions on moving to microservices.[3]

[0] http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-arch...

[1] http://www.slideshare.net/spnewman/principles-of-microservic...

[2] http://12factor.net/

[3] http://tech.gilt.com/post/102628539834/making-architecture-w...

Comment · 11 years ago
I feel like if you're building them brittle, you're building them wrong.

I had the pleasure of watching Sam Newman's tutorial on microservices. He's uploaded the slides here: http://t.co/2nhDBJK1oB

Building microservices requires a few changes in culture. If you are moving from a monolith to microservices, your entire culture must change how you look at problems must change and if you fail to do those things, of course your transition will change. It is not a silver bullet. It is a paradigm shift.

Comment · 11 years ago
Ack! No. I was mobile and it pinged me to login after generating the comment, then brought me to a blank screen. I'd thought I lost my comment.

That's a good idea though..If only I had the time

Comment · 11 years ago
What I find most strange about all of the photos of office design for "big companies"

Where does the actual work get done? Why are those pictures never included?

Comment · 11 years ago
The funniest thing about all of these "office design" photos that I see of big companies.

"Where does the actual work get done?" Why are those photos never included.

Comment · 11 years ago
You can no longer download from their website. So, I'd assume yes, we all wasted our time.
Comment · 11 years ago
I feel like perhaps I'm the only one concerned about this: (Somehow, “SmartOS + LX-branded zones + SmartDataCenter + sdc-portolan + sdc-docker” was a bit of a mouthful.)

Not only is it a mouthful, it means there is a much wider space for things to go wrong.

Comment · 11 years ago
Don't be confused. Paypal's Igor wasn't automatically detecting and taking action. See my comment. Max Levchin's original design failed.
Comment · 11 years ago
The reality is, computers are good at some things, humans are good at others (Remember how much effort it took google to identify cats in youtube thumbnails? Something any four year old can do?). Computers are good at sifting through large amounts of data. Great. Humans are good at detecting fraud. Combining them is best.

Peter Thiel writes about how fatal machine learning for fraud detection in his book, "Zero to One".

At Paypal, Max Levchin assembled an elite team of mathematicians to study the fraudulent transfers in detail. Then we took what we learned and wrote software to automatically identify and cancel bogus transactions in real time. But it quickly became clear that this approach wouldn't would either. After an hour or two, the thieves would catch on and change their tactics. We were dealing with an adaptive enemy and our software couldn't adapt in response.

The fraudsters adaptive evasions fooled our automatic detection algorithms, but we found that they didn't fool our human analysts as easily. So max and his engineers rewrote the software to take a hybrid approach: the computer would flag the most suspicious transactions on a well designed user interface, and human operators would make the final judgment as to their legitimacy.

Comment · 12 years ago
Thank you, this helps.
Comment · 12 years ago
"FREE KITTENS!"
Comment · 12 years ago
I don't know why you're being down voted either. In the moment I couldn't get past her wanting all of my things, and I couldn't get past having to do my presentation and letting all of my peers and company down. I froze and in the future that won't happen again, but you were right, I should have thrown my phone and hobbled away.
Comment · 12 years ago
Because you're human! What do you think got your ancestors this far! Do those values no longer apply because we beat certain environmental elements?

Are we to suggest that community support is as vestigial as the tailbone?

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton