ninjakeyboard

Really cool. Sometimes when I get angry I just want to turn people into babies with my hands.

I view 1-1.5 year jumping as more of a risk. At the level of maturity that I'm at it's actually more of a mental health concern than it is anything else. I encourage people to move fast but I also know from my own patterns that the fast moves are a sign of depression.

This guy has a biography online about what he did so screw that. Just post a link to this article if you re-enter the work force. But you'll have something to put there anyway.

I've used protocol buffers on a large project, evolving the messages over time. They are a fine choice.

The tone of this article is a little less than objective which I feel discredits it a bit. But hey it made it to the front page of hacker news so...

Some foundational stuff I usually recommend: - algorithms and datastructures (princeton coursera course) - functional programming will make you a better developer - "head first design patterns" is a book that will get you to understand the heuristic of design patterns in OO fast

"AV1 has the potential to be up to 20% better than the HEVC codec"

Can you clarify what is meant by better here? More compressed?

congrats you made it to number 2 on hn - I'm sure your revenue just went up a lot. The game actually looks pretty cool. I echo the price and platform. It looks like it would appeal to a fairly casual gaming category with a lower price. I'd pay a couple bucks but 7 or 8 seems high but I don't do gaming off of my phone so this game would appeal to me but isn't targeted toward a platform that I use.

Whether related to an app or solely to the OS, as well tested internally as new releases may be, it's still a new major release. Things'll iron out soon enough I'm sure.

Love, - guy who writes software and knows that all software is terrible

The term is used quite often in manufacturing. For a part when picking, for example, a part may have two colored squares on the label so the operator looks at the color on the squares to validate as an extra step. We call the colored squares the poka-yoke.

yeah my goal is to live a long and happy life of hacking and coding. My health is more important than being able to type a search into bob's computer without looking at the keyboard. But I was having a LOT of wrist pain.

Learn Colemak instead IMO - I've been using it for about 7-8 years. Here are my remarks to address your gripes from a long time alt-layout typist.

FWIW your ability to type on QWERTY returns after a while - you just need to keep using both. It's like a switch changes although it helps to have visual queues to get back into gear with qwerty I find. Otherwise my keyboards are all blank now including a blank kinesis advantage. If I use qwerty I need to look at the keys to start typing usually.

And my typing speed is probably slower than it was when I was using qwerty. I was reaching 120wpm peak on qwerty, maybe could do 100wpm with colemak (haven't checked) but I type much better as I learned the new layout with discipline - eg no cheating with wrong finger on keys - and I move my hands much less so my RSI is better. You can visibly see wear on my home row - a sheen that's on those keys from pressing them more than the other keys. My co-worker says it looks like I'm hacking on the matrix because my fingers don't appear to move when I'm typing.

Very cool!

I noticed Wikipedia references another app for terminal in C: https://github.com/Tiehuis/2048-cli

Might be interesting to compare.

Good for you young jedi. I started coding around that age as well. I made the mistake of not going through comp-sci but have still been able to work for Google, publish books, lead teams and companies and products. You'll do just fine.

You have the ability to write some code! If you want to get a jumpstart, you should take the princeton algorithms course (for free!): https://www.coursera.org/learn/algorithms-part1

Or read the textbook by sedgewick that accompanies the course. https://algs4.cs.princeton.edu/home/

There is very little math in there - it may take some elbow grease and mentorship to help to convey some of the ideas - but I believe that you could implement and solve most everything in there. That was my path - I had a teacher at the age of 14 who would explain to me how different algorithms worked and I would go and implement them. Drawing a circle (in memory - it was in C!) or sorting a list (we did bubblesort first IIRC!)

I think you could do it! I believe in you! The course material is approachable - much more so than basically every other algorithms/data-structures material I've found. it may take you some time but you'll be soooo far ahead with your thinking about code.

If you ever start working with Object oriented languages like Java, another book that may help you when you've gone down the road a bit is the Head First Design Patterns book. http://shop.oreilly.com/product/9780596007126.do It's very easy to read, mostly pictures. It is made to be very easy to read (all of the books in that series are so look around at them.)

It's helpful to do both - code and also take in some material, but at 12 I imagine some of the material may be a bit daunting. You're doing really well - keep it up.

Yeah for sure. That's kind of the idea with event sourcing in general, but I think with elixir/otp, it's easy to see how event-sourcing is only a persistence mechanism. Usually how I think about it is Event Sourcing (or gen server using a db as a recovery mechanism) "moves" the source of truth from a db into the process that owns the data.

Yeah I'm using kafka right now with small queues between processes (generally implemented as elixir/OTP gen_server). With a blend of RDBMS (postgres which is now a swiss army knife), Redis (also a swiss army knife), and zookeeper (mostly because I know it well and it's there with kafka. It's very useful for co-ordination across processes.)

Because the events coalesce into kafka, you can use a mechanism like logstash to spew this log data into eg elastic search and then use that for your queries. Or write to the db here (in process) or there (cqrs style.) There are different architectural approach used, and they all yield good results, of very high reliability in processing, if slightly "eventual."

It works well. We do use rdbms too, but a lot of the time we avoid reading from it after initialization (or after encountering an exception causing an actor to restart). Depends on the data though. Some places I read on every command because I know the risk front is small and it's easier for a jr to get in there and understand what's happening. A good rule is that a single process should own that data so you don't have to worry much about consistency related concerns. In microservices good practices, each service should really own its own data completely but I believe that it's fair enough to say a bounded context owns its own data (even if in a shared rdbms) if building at a smaller scale.

In terms of code, I'm usually building with some variation of onion architecture these days, where all context is build on the outside (eg receiving a request, getting info from state or db), and pure domain logic 100% effect free exists on the inside that receives all of the data from the outside and turns out some commands or events in response. This makes the important logic very testable, and easy to reason about. Core domain logic has no effects - not even logging - but only generates events/commands in response to commands and events. You never mock that stuff - it's the star of the show. Nor do you ever have to. The generated commands and events are later "applied" by the outer layer, logging, shipping them off to kafka, and/or writing some stuff to a database.

That's where I'm at today. I am working in realtime systems so it's a good fit for the approaches. I'm finding the software is turning out very well. We're working fairly quickly, the software is very encapsulated to a bounded context, the domain logic is clear in the core, easy to test and read, and change. Or even rewrite if needed.

I'm only saying it isn't the only approach, even if you're keeping the source of truth in memory. It's the most prescriptive approach for sure so is the one people tend to go for first but there be dragons in managing especially long lived journals. Migrating the journal over time, figuring out how to truncate it (especially if there is an initial creation command/event that describes the rest of the life, or periodic updates to the structure - you have to keep all of that data forever potentially to know that it's going to wind up being correct.)

And yes long recovery times are an issue unless you want to keep every entity in memory forever and ever, or you can tolerate extremely slow turnaround times. There are knobs and dials here that are subtleties that people won't think about until after they launch.

If you have a hammer everything looks like a nail kind of thing. There are other ways to handle problems that are only marginally different in how they persist and recover state, yet are far more usable for certain use cases. I'm extremely skeptical when I see someone gung-ho for event sourcing if they've never used it though. I tend to look at the problem very hard to see what else we could do for persistence while still maintaining the "source of truth" in memory.

I've worked with event sourced systems quite a bit in production and at scale, and have written a book on Akka and another one on related topics. While I have been an advocate of the approach, My experiences are guiding me away from implementing Event Sourcing in many use cases (especially where the entities are long lived). While CQRS is more complex, I'm more likely to implement CQRS without event sourcing, where an entity is responsible for its own persistence using whatever mechanism we deem suitable, and emits events that can be used for the view (or the data can be viewed as read only.) Ultimately a bounded context is there, and you send it commands and get out events. You have to evaluate the recovery and persistence mechanism based on your needs. Exactly once delivery is a pipedream so it doesn't matter how you're persisting the event and delivering it, evaluating line by line, crashing somewhere it's going to be possible to emit an event twice somewhere (eg if the outbound projection emits the event but doesn't persist its offset.) You need to deduplicate somewhere to get exactly once processing semantics. There _are_ simpler approaches to persistence that work just fine with the same delivery guarantees that work fine in the place of Event Sourcing. Nobody talks about any alternatives though - everyone defaults to event sourcing. My intuition guides me to look at other options having been burned one too many times, watching organizations collapse around 100% event sourced applications, etc.

I'm still working on event/message driven systems (today with Elixir mostly) but I've started to make architectural compromises to move away from especially event sourcing. Event Sourcing + CQRS may be prescriptive but it's very hard for new developers to pick up and understand the layers of abstraction underneath eg Akka + the Persistence Journal. And I'm not sure I can trust many of the open source libraries outside of Akka to be honest. I've had to dig into the depths of postgres journal implementations and apply windowing to journal queries for example because they weren't burned in at the scale I was working with (partially because I inherited an application with a single entity in a context which had many million line long journals - this highlights a design error though but hopefully you can see my point.)

You don't _need_ to use these patterns but you can still apply DDD and event/message based abstractions, and publish events. An entity can write its state to a record and then apply the state in memory as well without using a journal given you handle exactly once processing semantics correctly. This means there are knobs and dials. The problem with event sourcing in the greater picture is that it's descriptive of an approach, and there aren't many clear alternatives that people are talking about that work in similar system designs. If you have very long lived entities, or only a few of them, it gets especially difficult to keep the system alive over time, but for those use cases it doesn't mean you should stop receiving commands and emitting events.

You always here about the idea of the approach, never the reality of maintaining these systems, or the inappropriate use. In one implementation, there is one entity that receives thousands of events a day, and lives forever. How do you maintain the journal while changing the code, keep it alive over time? I've watched event sourcing and CQRS sink projects and teams. I've watched well paid contractors unable to figure out how to cluster and scale these systems. The barrier to entry for people to become effective can be high and you should understand the long view in terms of people required and cost over time and validate the approach for your use case very carefully. Again, the fact that everyone talks about event sourcing and no closely related alternatives makes it seem like the gold standard or the only option but there are other (simpler) ways to deal with your persistence in an overall similar architectural approach.

Are you using server side rendering? There are ways to make it harder. But ultimately you don't want to sacrifice the user experience. Why don't you require registration provided by a third party like facebook or google - it's one click sign on and you can make your access requirements extremely low.

IMO You don't need to specialize on a language or famework, but a problem domain, either technical (eg distributed systems, machine learning) or not (manufacturing, video, etc).

It's better to be a good programmer that's deeply experienced in a domain, then a great scala developer that doesn't understand the domains he's working in.

I'm more in the distributed space so I know elixir and scala very well with actor model and distributed coordination tools in my toolbelt. I'm not the best scala engineer but I can get shit done and it will be correct and work through all of the pathological conditions because I've seen a lot in this area. If you asked me to build a webpage I'd fall apart but I'm good at that specialization and have all of the tools I need to work with the technology I know today, and to build on to learn whatever technology is needed tomorrow (eg I've been working with elixir for a year but I'm extremely proficient at it because of my 6 years of akka experience)

I think many saas solutions that exposes functionality of some command line tool. Eg video encoding, as mentioned html->pdf, barcode generation, even just storing and retrieving assets.

I like this answer. It presents a framework for reasoning about why it turned out the way it has, and why it likely won't change.

I think also the motivation for (advertising) profit is what is driving the innovation on the other side.

Reminds me of this video https://www.youtube.com/watch?v=IHbaBd3h0FU

The salary is partly imposed on me as a constraint but we are also offering an unreal equity package vs what I've seen (multiple % in voting shares.) My salary is the same. And it's not low for Toronto. With my experience I know I could make at least another 20k but the equity compensates.

Our team is extremely small so the value of work contributed by each head (given the individual can successfully contribute in such an environment) is very high.

The issue is less finding takers and moreso finding the right takers. I've turned down people who were very interested because I wasn't sure about them. Unfortunately, I have been outbid on hires I was sure about which is very difficult to swallow. I would like to be able to offer at the upper end of the spectrum but the equity does have some value in the picture. I'm sure we could do an either or thing. Like you choose - either more cash or less with more equity. Because not everyone seems to be very interested in ownership. They just want to be paid.

There are elixir meetups held by pagerduty. PagerDuty is moving primarily to elixir and have a large engineering presence in Toronto. Their interview is a bit tough. I know several good devs who didn't make it through the process. It's usually something like two-sum problem (two lists, does a number from one list sum to equal 0 from the other list?) in a 40 minute live coding exercise over the phone. You can shoot me an email if you want to chat - alayablue -- at -- hotmail.com and I'll reply from my work email address. Let me know if you do send an email - I don't use that account. It's always worth having a chat so please do reach out.

Yeah. I'm struggling to find really solid engineers in the city. I need really experienced people and I can't find anyone. Even the most sr consultants and contractors have a lot of gaps and don't understand the real edge cases that appear in systems.

I was lucky enough to learn from a team as we went through a google acquisition and watch and learn as the technology was scaled in both the context of a startup, and later inside Google. I was the whitebelt in the back of the room but that experience of working in that team was the most valuable experience I could have ever hoped for and I still regularly mail the people that I absorbed from to let them know how grateful I am to have taken me along on that journey. It's not a common experience but that completely humbled me and fixed my dunning-kruger arrogant ass.

The wages in toronto have skyrocketed in the last couple years. I'm looking for functional programming people if you're interested I can pay at least $120k/year and offer considerable equity to work on realtime systems. We're profitable and not funded. We have a couple seats to fill and I'm having a hard time because people in Scala circles are expecting $150k/year in Toronto. Many of my peers are making $150k no problem in the city as full time employees at your average tech company.

If you have elixir or scala experience, like FP, like realtime problems...

You shouldn't need to "Learn Excel" if you are a programmer. You use Excel or Google Sheets or Emacs' "Simple Emacs Spreadsheet" (SES) or whatever tool to do things you need to do, and learn whatever features you need as you go.

I personally use Google Sheets for: - Impromptu project planning and release tracking in small teams - Creating test plans for release testing

And not much else as I can do most other things using other tools. If you want to pivot data and do data analysis, yeah you can use a spreadsheet. Or you can use python.

I wouldn't go out of my way to learn the deep depths of excel when you could take time to learn sed or awk or columnar and multi-cursor editing in emacs or other tools that, beyond tasks that can be accomplished in excel, will help you in a wider variety of tasks.

But by all means I would be using excel for simple spreadsheet things. It's not a tool I'd go out of my way to spend time on learning excel as a programmer without a task infront of me as being a curious technically apt programmer means it's quite intuitive and fast to learn whatever I need to accomplish things in excel as I go.

Learn emacs, learn colemac, learn awk, learn clojure, learn pandas. I don't think you need to learn excel beyond basic spreadsheet functionality.

Here is the info: https://www.webmd.com/allergies/news/20160509/anticholinergi...

I would recommend avoiding anticholinergics!

I would be careful with dimenhydrainate as it is found to be related to dementia likely due to the fact that it's anticholinergic. It's basically the opposite of a nootropic.

In case anyone is curious about L-Theanine, it's very often used by people with interest in Nootropics for focus along side caffeine. The Theanine-Caffeine stack is considered to be the sort of entry or gateway into nootropic territory.

Yes it does. But not in large quantities. The study doesn't seem to suggest very large doses of L-Theanine were used either though. I usually take 5-10x what they were using in the study :P maybe I should reconsider my dosing.