Hacker Newsnew | comments | show | ask | jobs | submit | cwbrandsma's comments login

1. Dumb terminals never really left us. They are in active use all over. 2. The current web trend is using more of the browser CPU, as opposed to the server CPU. Heck, I have entire apps that don't call the server after load at all. I don't remember being able to execute code in a dumb terminal (possibly you could...I just don't remember it).

Dang it, now I'm nostalgic for playing MUDs on a VT1000 in the 90s.

I agree there are some problems with the ui, but at the same time the number of devices they design for is quite large (desktop web, mobile phone, set-top boxes, Apple TV, Google TV, Amazon TV, etc). Creating a UI that is consistent between all of them must be a bit daunting.

So don't do that. Make a few UIs. They are a big company, they can do that if they actually have anyone who knows how to program.

I remember hearing a story (probably apocryphal) of one of the armed forces trying to use image recognition to identify tanks. So the took a bunch of scenery pictures with and without tanks, then fed those pictures to the computer.

After some processing the computer was identifying pictures of tanks with 100% accuracy. So the group started showing off the software. Some guy proceeded to take a picture outside that had a tank in it, then fed that picture to the software. No tank found. More images given, more problems found.

So the group went back and look at the their tank image stockpile. All the pictures without tanks were taken in the morning, all the pictures with tanks in the afternoon.

When they thought they were training the software in identifying tanks, really it was identifying time of day.


Twin Falls, ID is right on the edge of the Snake River Canyon, with the Perrine Bridge connecting it to all things north of the town's location. We frequently have bridge jumpers, as it is allowed.

Last month a 73 year old guy died when his second parachute didn't deploy correctly. He needed the second parachute BECAUSE HE LIT THE FIRST ON FIRE!


I don't mourn people who die doing crazy things, so long as they are smart enough to know better. For some people, this is how they celebrate life.


For those looking for here is the video: https://www.youtube.com/watch?v=0LzIWtE7a6k the article linked above linked to a removed copy it appears.


I just want to point out something that might be relevant, namely that as a combat vet, I learned that adrenaline is a drug like no other, and it's also extremely addictive. A key point that many adventure seekers fail to take into account, and I think it can sometimes adversely affect their analysis of situations at the moment of truth. Always be prepared to call something like this off, up to the very last moment, don't let the excitement or pressure overcome the logical side of things.


I really hope more studies are done about how adrenaline addiction adversely affects behavior of people, particularly in jobs where adrenaline inducing events are common, i.e. police, sports/athletes.


This is like equating those who drive jeeps on two wheels to everyday drivers.

That incident is as relevant to everyday BASE jumping as https://www.youtube.com/watch?v=ouicSLOc_K8 is to https://www.youtube.com/watch?v=UfipAgNRDx0


I feel bad for his family, but that's a Darwin Award winner if I ever saw one. Unless he had a terminal illness. Then I applaud him.


C# can accurately subtract decimal numbers without having to invoke a webservice or use a third-party library. I'd call that better.

(Note: I spend most of my time writing JS, but am extremely familiar with C# and Java)


I was laid off during 2002, during the peak of the dotcom bubble burst. Effectively I was out of work for 3 months, but didn't find full-time work for 9 months. I ended up having to borrow money from my parents to make ends meet (all payed back now).

At the time, I was very well versed in Delphi and was pretty good with C#, SQL, MDX, and various web technologies.

I spent my morning looking for new jobs, then in the afternoon I was writing my own MDX library for .Net (MDX is the Microsoft Analysis Services language/API). Eventually I was hired on by a contracting firm where I stayed for about 4 years.

My Take aways: My best advice is to stay connected with the community. Find a developer group that meets regularly, attend and present. I also learned I suck at running my own business.


Better are books that can be read on their own...and are part of an expansive series

* Foundation * Dune * Discworld * Hitchhikers Guide to the Galaxy * Hyperion

Even worse are 5 book sets (Belgarion and Eddings novels)


I used to live in Michigan...burritos were terrible there. I seriously thought the entire midwest had burrito blite. I also spent a lot of time around Bemidji many years go, I don't remember seeing a burrito there.

Hopefully you are right and Minneapolis is better. But for my money Phoenix has some great burritos (I don't live there, I'm in Boise)


American here, I don't pay that much. Netflix/no cable $8, phone is $90 for 2 phones (T-Mobile), Internet is $50 (50 mb cable).


it is 4 lines on T mobile for $150


I might be behind on state of the art these days...but my current api has no GET requests, everything is a POST. So in that term, we are not restful.

We had a couple of problems with GET requests: all of our data ended up in the url (we have too much info that has to be passed, we stopped working on some browsers), and the data returned could be cached (which is a HUGE problem for us).

Now, POSTs can also be cached, but there are easy ways around it...you can do the same thing with a GET, but that means adding more information to the url.

Anyway, one we got to the point of forgoing all GET requests, we ended up just doing everything with a POST for simplicity.


Yeah, REST is nice for some things, but for normal APIs, you're calling them from a programming language, so calling remote functions (RPC) is very similar conceptually to calling local functions. You might not be able to guess the paths as easily as REST(?) but then again trying to make things REST style doesn't always work out when the things don't allow all the REST verbs or don't fit into a hierarchy, etc.

For serving a filesystem over HTTP REST is great though. And all that caching stuff comes in handy.

From a practical API standpoint though, having two different encodings (GET in url with url parameter encoding, and POST with form encoded or JSON) is a pain and has caused a number of minor bugs and definitely extra work.

Using HTTP is basically a socket for JSON RPC style calls is I think the most straightforward route. In this you have one RPC per request, POST only, with a JSON request body and JSON response. If you use keep-alive it's similar to a socket but can go through some firewalls a bit easier, and has a built-in framing format and metadata thing. Also it works with existing log monitoring tools and frameworks.


I did the exact same thing in a project of mine. We're shifting away from that and put our data in cookies, so we can cache some of the things our API send out.


You can also use localstorage these days. It's great not having to send data on every request.



Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact