akeating

Grio.com | Senior Ruby/Elixir Engineer | full-time | San Francisco | REMOTE

https://grio.com is a consultancy that builds custom software. You will work on a variety of projects. Experience with Elixir, Ruby, Typescript preferred. Fluent English is a must since you will be collaborating with clients.

More info at https://apply.workable.com/grio/j/4CA4E58D47/

I think that's a concrete area for you to explore. When I hire, I'm often looking to hire to fill a specific skill gap on a project. I look for the specific skills I need right now and for skills I think will help the employee grow into other / more senior roles. But in the initial assessment I'm look for indications that the candidate can hit the ground running and be productive in a relatively short period of time. Of course sometimes I can't find the exact right candidate end-up broadening the filter. The learning for you here is to focus on selling you abilities in what the hirer is looking for. The rest are nice-to-haves.

Nice. I used this a dozen times over the outage period. Thank you for your work!

Rust Elixir Rust=>wasm Flutter Elm

I've been watching Revolut who introduced something like this a while back https://blog.revolut.com/introducing-disposable-virtual-card...

There's a nice implementation of subscriptions over at https://hexdocs.pm/absinthe/subscriptions.html#content for Elixir.

yeah, I considered holding onto a pair of old 2950s but ditched them considering my peak electricity rate is 43c kw/h. This setup makes me shudder.

The typeyness of graphql gets you documentation, validation and a way to communicate intent with fellow developers in a way that's agnostic of the language and transport used. Win, win, win, win.

Some Hex download details https://elixirforum.com/t/the-buzz-and-activity-around-elixi...

I wonder whether you know how to nurture leaders under you and how to delegate effectively? Many founders are relatively inexperienced and I understand this might not be the case for you. But if it sounds like something that resonates, consider reaching out to a mentor who can help with this. With an exit on the horizon, there's an end-game. It's likely the acquirer would anticipate you would leave anyway. You might start a dialog about building the skills of a replacement, you know, if you get hit by a bus, wink wink.

It's useful to think of the work of m Elixir processes being distributed to n cpu cores by the BEAM scheduler. An Elixir process is not a system process in the way we usually think of the word process if coming from a non-BEAM world.

Buying one of these http://www.concept2.com/indoor-rowers/model-d worked for me. Full body workout I can do at home.

If I read this correctly, you're interested in formatting your resume in a way that (hopefully) gets the right data into the right place in the target systems. Many of the systems you reference use third-party software such as http://www.sovren.com/ that attempt to fill the void. You will end up optimizing your resume to fit certain categories. Implicit in all this is that the end user may only utilize a subset of all the possible categories of resume information. You might consider playing around with the Sovren api, or use a fairly well known format, such as the LinkedIn profile pdf.

Elixir and Erlang actually map remarkably well to the _web development_ use case. When every request gets it's own process and shared services are abstracted away, the mental model is quite simple. Use Elixir/ Erlang and you also get to use server push architectures with ease. Want server state to write your own device-sync? Need to write web-hooks? Want to count requests? Need to guarantee uniqueness of a combination of variables in a distributed environment? Want to do server some requests requiring heavy-lifting while also serving short-lived requests with low latency? Choose Elixir / Erlang for web development and as your needs evolve (and they will), you're likely to be surprised and delighted by how much you can achieve before you need to move to a polygot or micro-service-based architecture.

The option to look for, irrespective of language of implementation, is "context". An example of usage may be found in https://github.com/graphql/express-graphql. Basically the context (session or user data) is passed into any resolve function you define, so you may relate operations to permissions using some mechanism you define.

Edit: grammar

You will always find something valuable that will improve your life. For example, software engineers can apply the abstract learning from Coursera's course about functional programming in Scala to any other language. Focused learning can generate more tangible and immediate returns, but don't discount the value of learning generally. It's likely to be a significant factor in keeping you relevant and consistently employable over the long term.

I find that timely feedback is essential to the pr process working effectively. A few things can help: * submit RFC prs that are not intended to be merged early so architectural or design issues can be socialized early * break your commits into logical chunks * open an epic branch and merge smaller commits into it. When ready, open a new pr to merge the epic into master.

This does sound like a culture issue. Everyone should be empowered in this process and everyone needs to be involved. I think of it a check-and-balance, but we all have a responsibility to complete features to a high standard, in a timely manner. If a feature is delayed because reviews are slow, we're all responsible.

I think the author raises some valuable points but does not emphasize the key point about logging; that _logging has relatively limited applicability_. If you think of logging that way, you log everything, but keep only a time-bound window of log data. Around two weeks is plenty because most of the times you need to access the detailed log information is same or next day. I think careful attention should be paid to annotating log messages in various parts of the stack with some piece of data that can be used to correlate messages that are important to your use case. E.g. make sure a customerId or invoiceId or something logs through various levels of the stack.

There is a strong case for transpiling if you have a node backend. Presently we use ES2015 features on the backend that wont work in the front-end code without a transpiler. It's not really inconvenient, but it would be nice to use many of the ES2015 features in both places. Shared libraries in particular can be built using ES2015 features instead of settling for the lowest-common-denominator. We also use make in our build tooling.

I've been watching Elixir (and Phoenix Framework) as well. In addition to lightweight processes, the functional style, immutability, pattern matching and Rubyish syntax are appealing too.

This resonates with me. In my view the real superstars in this industry are people who listen well, have humility, are grounded in reality but are smart and confident.