The bolded would happen via websockets. Most web technology has traditionally been pull, meaning nothing happens unless the client (browser) requests it from the server. With websockets the server can push to the browser any time it wants, w/o the browser having to poll every second or so.

Polling is is the traditional method of achieving something like server->browser communication. But it eats resources and isn't as efficient as push.

Push makes sense for something like a real time game or chat application. A lot of people want to use it in places where it's really not needed. My boss was obsessed with websockets and kept pushing for us to find a place to use it even though our app really didn't need it.

Web sockets sound a lot like asynchronous data calls or something like in Ajax/ajaj

Edit

Aside from the server push mentioned above

Also, part of learning that sucks is trying to figure out a decent excuse to use the thing you're trying to learn. Maybe when you're learning you just need to shoehorn it in for the sake of getting the concepts and worry about using it appropriately at a later time.

Right, but websockets keep an open channel of communication between the browser and server, that the server can push to any time w/o a request from the browser. Traditional sockets for web requests (straight http calls and ajax) have short-lived sockets that close when the original request/response is finished.

Not really. Asynchronous is still originated by the browser. Websocket pushes are originated by the server (via an open socket).

Btw I have asked a bunch of smart programmers I know how a socket works under the covers, and read a lot, and it's pretty damn hairy and confusing. Anyone want to explain the nuts and bolts of a socket? Not what it does, but how it does it.

Lemme give an attempt to explain how it works. I'm not sure which pattern I'm referring to (mediator or observer pattern or maybe something else altogether).

Simple example is : user --> resource <-- server

The resource has some method that accepts push/pull requests (per the vocab used in this thread). Those pull/push requests presumably trigger an update in the corresponding 'endpoint. In a pull request [ajax request], the server, receives some updated values. In a push request [socket connection], the user receives an updated resource based on something that some other client has done. Maybe you're logged into gmail on your iphone, desktop, and laptop. You sent an email on your iphone. All logged in clients receives an updated list of sent emails (iphone, desktop, and laptop) even though you only sent the email on your iphone.

Yeah - that sounds right.

It's similar to data-binding on the front end, where if anything changes the underlying data, anything watching that data is triggered to update its view.

But keep in mind the client can also get updated values from a pull request. The client initiates the request, then gets updated values from the response. This is how the browser gets updated information like 99.99% of the time in the current web. Push is still an esoteric niche thing.

I work with knockout on my employers website. It's a lot like what you talk about except for one small difference. There is one initial request to fetch all the data. It is saved in an initial view. That becomes the 'authority' on the current state of the data. On saving a resource, that model gets updated. There is no request back to the server to request the new state of the resource. We just update various values to reflect what the state the server would return if it was queried .

Grunch, Websockets seem like a protocol "on top of" TCP. BSD sockets are pretty much the basis for providing an API for TCP on the systems programming level.

going with observer here iirc, but that makes the connection between, say, the chat client and chat server we wrote two semesters ago a web socket? Or does it have to be via a browser?

Edit

oh, duh, or I could just click the link to rails' site and read about the features:

Cool thanks. I'm getting a free license for a few weeks. My job uses c# and asp mvc so I figured I would do some of those. Also angular 2 would be worthwhile.

My boot camp did spring and I learned a lot about it so I may check those out too.

I liked spring and was able to build decent apps with it, but asp/.net is so much easier to get started.

feel dumb not having clicked this earlier (due to how links show I thought it was basically a lmgtfy-style post XD), but yeah, basically exactly this. Or, this combined with the other link.

Fantastic finds, thanks to both of you just_grindin. Adding this stuff to the resources thread.

Have you tried spring boot?

no, ill check it out if I ever decide to go back to Java.

I gotta admit though, between the ease of set up, the syntactic sugar in C# get/set methods, anonymous methods, and LINQ, I really like C#. but I think it was better to learn the hard way with all of the Java explicitness.

I'm sure this will be surprising to people, but I've started applying to jobs in the SF Bay. I know the endless attempts and persistence must be sickening, but sadly, it's the way I am.

There is a major difference between how different cities respond to my resume and projects.

Entry level:
SF and Austin:
Form letter saying "sorry, you don't have the skills we are looking for."
LA:
"Hey, I have this SR level position you may be interested in. Are you familiar with CVS or Git at all?"

For mid / sr level jobs, the responses are quite different in each city.
LA:
"Oh, you know, there's company X up the street. They are looking for Erlang programmers."

Austin:
"Why the **** are you wasting your time on projects no one gives a **** about?"

SF:
"Those are some impressive projects, especially for a self-taught, keep up the good work. Unfortunately, we need someone who has real world experience."

Why are you trying to get an entry job in one of the most expensive places to work?

Startup life:

• 12:10 - start to line up in kitchen/cafeteria area
• 12:15 - catered lunch is served, eat with coworkers
• 12:50ish - back to desk to work

It hits two very good notes: we get to be social with coworkers, while also not taking a big chunk out of the day when I usually would prefer to stay focused and get back to work. (edit: and a third, variation in food every day instead of eating at the same 3 places)

Like, at what layer? I think your network card sends packets over the interwebs to a destination network card and then there's 7,000 layers of abstraction between the physical hardware and your node application that I never ever want to know the details of.

I don't understand the question.

I've worked at places like that, my gf works at one now. It's pretty sweet but eventually you get tired of the food rotation.

I'd settle for knowing exactly what an "open socket" means at a nuts and bolts level, and why it's so much more resource intensive than *not* keeping the socket open.

http://discuss.joelonsoftware.com/de...gn.4.652240.24

best i can find on short notice, not much more informative than "it uses lots of resources", but it sounds like distributed apps can handle it tho

Okay this is good, from your link. I was wondering why an unused open socket would take up so much server system resources. According to this commenter anyway it doesn't, which makes a lot more sense to me.

open sockets select vs. epoll


Without getting into weeds too much, the above article alludes to the overhead that can exist with many open connections. The select() method utilized for a server in handling connections doesn't scale well and Linux version 2.6 IIRC introduced the epoll system call which does scale well for servers with a large number of open connections. Robert Love explains this well in his excellent book, Linux Systems Programming.

Salaries are also absurdly high.

After cost of living I don't think it's anywhere near absurd.

People are raising kids on $13/hr up there. Why would it be beneath me to stay in a flop house in the Tenderloin whilst earning meager entry level wages?

The Bay may be a better and easier place to find and maintain work. I don't know. Just seeing how that may go.

studies indicate you would be wrong. even accounting for cost of living, SF is still like top 3 places in the country to live re: salary

because you enjoy not being murdered?