nathan_long

On my 15-inch MacBook, I have a full-screen terminal running tmux, split down the middle with Vim in the left pane and a shell in the right pane. At the smallest font size I can stand in decent lighting, I can get 88 columns in the left pane. Usually I want the font larger.

80 seems good to me.

A discussion of how Erlang processes help us build scalable and reliable systems in Elixir.

This may not be news to developers, but might be useful for broader company discussions.

This is really murky to me. As a professional, I keep notes as I learn things which may or may not relate to my current employment. The notes are my property and part of my knowledge base that I bring to any job. But I suppose I indirectly receive compensation for knowing things, so I need a commercial license?

Or what if I start taking notes on some random subject for fun, and eventually I write and sell a book based on them? All of a sudden I need to start paying a yearly fee?

It's not a prohibitive amount of money, but I'd be much happier with paying a one-time fee for the current version, then buying future versions if I choose to.

I work at a large tech company on a young team (average age is late twenties). In my experience many don't view working from home regularly as a benefit. I understand that must change drastically when you're middle aged

Yes, and there is some correlation between age and seniority. If companies are so eager to hire senior developers, they might consider the preferences of candidates who have been working long enough to fit that description.

So you're considering Candidate A, who lives in SF, and B, who lives in a small town.

You decide that B has to compete with A on talent, but A doesn't have to compete with B on price.

Does that make strategic sense?

It cuts both ways, right?

Companies: "I don't have to pay you $big_city rates because you live in $small_town and nobody there will offer you $big_city rates."

Candidates: "I don't have to accept $small_town rates because I work remotely and can work for a company in $big_city."

Hiring is more difficult. It's not that you can't find applicants, but the people capable of performing without direct supervision is (mostly) a subset of those capable of performing in an office.

OTOH, your applicant pool is limited only to the time zones and legal jurisdictions you're willing to hire from. If you're office-based, it's limited to those who can reasonably commute there.

Yep. But I'm not lugging a crock pot on a plane. :)

There can be a fair amount of lag time over messenger and this occasionally blocks the completion of work.

Agreed. But the reverse is also true: it's harder for people to interrupt you.

It's impossible to have a company potluck.

That's the same risk you have with any open source project.

Yes and no. The larger the number of dependencies you have, and the larger number of maintainers that are behind them, the more chances you have of one of them containing malicious code.

I think you're pretty safe from Phoenix or Rails or NodeJS getting owned because so many people work on them. But one of the thousand small packages you use may belong to someone careless or malicious.

Lumen may be the answer to this in the future: https://www.youtube.com/watch?v=uMgTIlgYB-U&list=PLqj39LCvnO...

The common retort from SPA devs is "what about offline?" Since LiveView keeps state on the server, it doesn't really work offline.

However, 1) you can add custom JS using LiveView's hooks, which might be enough for very simple offline behavior and 2) many SPAs don't work offline either.

If offline support is a major part of your app's design, LiveView isn't a good fit. But you could still use Phoenix Channels (the building block underneath LiveView) to provide fast push updates to your client. See the channels docs for an idea of how they work - https://hexdocs.pm/phoenix/channels.html

The only modern web problem that Elixir isn't ideally suited for is heavy number crunching.

I would caveat that in a couple of ways.

First, suppose you have a web app where some requests involve heavy number crunching and others don't. In web frameworks where 1 request ties up 1 OS thread, a burst of heavy requests could gobble up all your available connections. Phoenix would use one cheap BEAM process per request, and the BEAM's preemptive scheduler would ensure that other requests are answered in a timely way and that all the heavy ones continue to make steady progress. So although the heavy requests might be completed more slowly than in another language, the overall system would remain more responsive.

Second, if you have need for heavy computation or data structures that work better with mutability, it's possible to (eg) use Rustler (https://github.com/rusterlium/rustler) to implement that part in Rust. See https://github.com/rusterlium/rustler for a story about doing this.

The answer is applicable. LiveView is implemented using Phoenix Channels.

You can see some other examples of LiveView apps at https://phoenixphrenzy.com/results

Chris McCord has given some talks and explained this - eg see https://www.youtube.com/watch?v=8xJzHq8ru0M at about 22 minutes in

I like to say that the BEAM's preemptive scheduling provides non-blocking IO AND non-blocking computation.

To expand on your workload description: things like waiting for a database query or an API result are smoothly handled in this paradigm; the process goes to sleep for a bit whle another request is processed.

If your workflow is like a delivery truck which makes a lot of stops, "faster trucks" doesn't help much with throughput. "More trucks" is better.

Another consideration: Phoenix PubSub makes it simple and performant to add more servers. So if one (say) chat app server can provide acceptable performance for N users, you can serve N more users by adding another node.

See the architecture of Phoenix Channels (which powers LiveView and other websocket-based solutions in Phoenix): https://hexdocs.pm/phoenix/channels.html

Imagine this: you set your browser to download only the first N bytes of each image, showing you a decent preview. If you want more detail on a particular image, you tap it, and the browser requests the next N bytes (or the rest of the file, if you prefer).

And to enable this, the site only needed to create one high-resolution image.

Seems like a victory for loading speeds, for low-bandwidth, and for content creation.

I think FLIF looks incredible.

Are you being serious? If a bank "locked" its vault by tying the door closed with yarn, would you say "at least they locked it"?

This was a contest to show off what Elixir's Phoenix LiveView can do. More about the underlying tech at https://dockyard.com/blog/2018/12/12/phoenix-liveview-intera...

Stallman was arguing that from Minsky's point of view, he probably had no reason to suspect that he was not dealing with a consenting girl.

"Consenting girl" is a contradiction. A child cannot legally give consent for sex. If he knew she was underage and if he had sex with her anyway, that was criminal.

The classic programmer corporate power move is wearing whatever you want to the office.

Could we just avoid cookies altogether, and store session info in local storage?

Several possible issues there:

- If the session is large, it eats space on the user's machine and bandwidth in requests - The session can't be shared across devices - Security concerns. You don't want to trust the user to tell you what their current state is - especially if it's "I have this much money in my account" and the like. Even if you encrypted the data, they could resend the same state at a later time - "oh look, I have a full wallet again!"

You're much safer if all the user sends is "here's who I am" and every bit of associated information is under your control server-side.

Because unless you are some sort of celebrity engineer, "interview is a conversation between both parties" is nonsense.

I disagree. Unless the candidate desperately needs this job, he/she can walk away. The candidate is free to consider "company won't bother to answer my questions at the point when they have most reason to be nice to me" as a bad signal.

I am specially referring to companies that don't really have to care about your feelings towards their interviews

"This company doesn't have to care about my feelings because they are huge and have lots of applicants and a giant incessant interview machine chugging through them efficiently" is certainly something I'd consider in whether I want to work for them, because it tells me I'd be a cog in a machine. (And if enough people consider that, perhaps they will have to care.)

To the parent question: I wouldn't ask a whiteboard question exactly, but I would certainly ask some questions about existing architecture and rationale so I have an idea what I may be working on.

Unless you add random delays to each trade.

you expect us web developers to cater to every different device out there? i am sorry, but the whole promise of the web is that i don't have to do that.

A basic HTML document with CSS styling will adapt beautifully to any screen and requires very little CPU or memory. Write once, view on every device with a browser. Publishing content is also part of the original vision of the web, and luckily HTML forms are also accessible to any device.

Yes, you want to write apps, and perhaps that requires more from a device, and maybe you don't want to cater to poor Indians. But lots of sites are sending down 3 megabytes of JS to display an article and run 48 ad trackers. That's a crappy experience even on my smartphone and decent WiFi.

I'd also wager that there are many, many "apps" you could write which could be 100% server-side rendering and simple markup, and which would be super useful in the developing world. Think Craiglist and Ebay - the kind of applications that help people share their location and agree on prices of goods.

The "use anywhere" promise of the web is easier to keep if you lean on the web's fundamentals instead of writing a browser to run in the browser and shipping it to every user.

Sounds right, but she wasn't purely mercenary like her friend Charlotte, who admitted to marrying Mr. Collins for his money, which filled Elizabeth with horror.

Depends highly on the employee's value to the company.

Also, if the employee has very marketable skills, they may be happy to leave a job whose hourly rate has suddenly dropped.