mrdoops

The company moved into a new office for a few months that had terrible cell service inside the building. Everyone had to do phone calls outside. But having Fi meant I could do everything on wi-fi. I think it's only a matter of time before features like this become ubiquitous. Do we really need cellular networks if something like Starlink beams high speed internet to every corner of the planet?

I'm especially fond of his description of boundaries and the trade-offs of different kinds of contracts between bounded contexts. There's also a lot of good insight into how we abuse the database and couple ourselves to it for the convenience of CRUD. Really feel like I should've picked up this book months ago.

Lift some weights. It might seem unrelated, but it's very crucial to improving your ability to deal with anxiety of all kinds. If you don't have experience around weight training equipment, then pay for small group training. Not only will you get a low-stakes opportunity to practice socializing, but the weight training will improve your testosterone production and your ability to regulate anxiety.

I should've done small group training years ago. Such a good investment.

Persisting a log of events. Used with CQRS and event-sourcing to decouple the Read model(s) from the Command layer for benefits like: multiple read models (projections), time-travel and audit-ability (rebuild the read model to certain point in time), and decoupled contexts.

Event-sourcing can be a really useful tool in many domains, but especially where having a state-of-the-art audit log is helpful.

> "I think Elixir has reached peak adoption"

I'd say the opposite. Core libraries have reached stability and engineering hours are switching to making easy what classic imperative/OOP paradigms have trouble doing:

- Dynamic web development without giant Javascript dependencies(Liveview, Drab, etc)

- Scalable distributed systems without giant teams (Firenest, Phoenix Channels/PubSub)

- Concurrency and data-infrastructure (Flow, Genstage, OTP)

- Reactive event-driven systems: OTP and the Actor model makes event-sourcing easier than you'll see anywhere else.

- Usual conveniences: User-management, HTTP clients/libraries

The next 2 years are going to get wild for Elixir.

We've scaled our networking of information without scaling the quality accreditation of information.

I started learning Ruby/Rails early last year. After building a couple projects in Rails for some clients, I switched to learning Elixir/Phoenix instead. Rails has a lot of magic and implicit behavior you need to learn to use effectively. I still love Ruby; the ecosystem is very mature and stable and the language is just so damn expressive.

I switched largely because of the applications I wanted to build were very 'Reactive' and message/event driven. Elixir being an Erlang/Actor-Model derivative with the expressiveness of Ruby was a perfect fit.

Elixir's ecosystem and community hasn't had as much time to develop as Ruby, but it's still very capable and you're not going to run into scalability problems.

If your goal is to skill up and get a job asap, maybe Elixir isn't ready yet, but I'd pick it over anything else to build a greenfield application in.

Best investment I've ever made is a small-group training membership. The workout is good, but learning the exercises I can do in my bedroom when I'm feeling restless is priceless. Very enabling.

Nothing wrong with Rails, especially if the team knows it well. Time to develop is the real cost in software most of the time.

If Github wanted to integrate a lot of real-time features, then Elixir + Phoenix can't be beat. Depending on what they replace, a 10x in performance and a fraction of the servers needed is a nice win.

I think I'd rather technology be dispersed without regulatory impedance. There's still the problem of how to reward/incentivize innovation and development of new technology, but maybe the benefits outweigh the costs or there's ways we haven't thought about how to reward and incentivize innovation.

Both are great reads. Fire Upon the Deep had some cooler concepts, but narrative-wise I prefer Deepness in the sky. The emotional response I had to the memory-control-slavery aspects made my blood boil.

Don't even need Ajax anymore. You can render on the fly, and deliver new HTML over websockets. The gap between SPA and classic server-side rendering is getting smaller fast.

https://youtu.be/Z2DU0qLfPIY?t=14m58s

I'm also doing Startup School and I like the approach so far. It'll be interesting to see how they handle the scale of the current number of companies. Lectures are easy to post online, and homework/exercises are easy to distribute, but personal feedback requires individual attention, and that's not easy to recreate. The 'office hours' with groups and the vote-based-forums are a good idea to recreate some of that missing personal interaction so it'll be interesting to see how Startup School evolves.

Elixir is fantastic, especially in these use cases because it allows for stateful in-memory representations of an entity with less development burdens than elsewhere.

I find it useful to have a GenServer for complex entities like state machines modeling business processes. I'm fine with the simple entities using the database schema as the state definition. However with the complex entities I still find I run into the classic ORM problem where the database structure doesn't perfectly fit the domain's pure business logic representation.

UBI is probably a bit too far in one direction to be a palatable solution. However Healthcare not being a financial concern for an individual or family is a very compelling idea.

But can a universal healthcare system resolve many of the emerging rent-seeking behavior costs peripheral to the actual hospital costs? Things like medical supplies that, in the U.S. are significantly more expensive than elsewhere. Would a universal healthcare system only further subsidize that kind of exploitative pricing?

Looks like Ecto.

https://hexdocs.pm/ecto/Ecto.Query.html

"Entrepreneurs with experience, money and connections are more successful than those who aren't."

I think it's more intended to be utilized as an abstraction in something like Apollo. It'll be interesting to see what sort of cleaner patterns emerge out of using Contexts under the hood.

I feel like the direction web and applications in general are heading is that of near-native performance in a sand-boxed execution environment managed by something like a browser. This potential is what excites me the most about webassembly, even more so than enabling the transition away from Javascript.

I'm in love with the simple explicit composability of everything in the Elixir ecosystem. In Phoenix everything is a pipeline from the connection leading down through the routes, controller, etc. Phoenix is just a plug in a Mix application and it doesn't impose itself in everything I do. I'm not a Phoenix developer, I'm an Elixir developer who happens to be using Phoenix to manage web traffic.

I think this is where Rails and Phoenix diverge in philosophy, Phoenix prioritizes explicitness and minimal assumptions with how and what you're going to do with their tool, whereas Rails is famously opinionated providing a 'Rails way' of doing most things.

What Rails does, it is very good at, but when you move outside of its expertise, you'll may find yourself in hot-water fast. Phoenix can be what you need it to be, and when you need to do something outside of Phoenix's domain everything is composable, so pick and chose what you need.

I don't think mining is the best application of utilizing client side connections. But surely we can find profitable ways to distribute computation. I'd be willing to divert the resources of a small sandboxed vm of sorts to websites if it meant less/no ads. It'd be fascinating to see what people could come up with if there were a publicly distributed Lambda/Serverless sort of capability.

I think the modern presidential role needs more technological savvy and broad-scale systems thinking than in the past. I'd put those abilities at a greater weight than typical political communication / dealing. There are tech CEO/Founders/Businessmen I would rather have in the White House than Zuckerberg, but there are very few politician/lawyer types that I would prefer over Zuckerberg.

Facebook's practice of experimentation and data-driven decision making is something our country needs more of. Incentives are pretty out of wack, in many cases the only way to align incentives is with information systems regulating more complex relationships. I'd also like to see some really aggressive pushes towards infrastructure improvements in internet, education, and transportation . All of these are things I think Zuckerberg would be a good bet to organize.

Some of the more interesting AI research is being done in the area of developing very accurate models of the real world. This way the many varied iterations needed to develop the AI model can be done without the same physical limitations of aggregating human data. Games are definitely in this same realm, although it's not always practical to make a human playable simulation-game and an AI playable simulation game given development constraints.

What I find fascinating is what AR might do for training AI models. To execute on AR we'll need to digitize a model of our physical surroundings so the software can interact. At that point we'll have a compelling pipeline of actionable data in regards to machine learning - especially for robotics.

One of the biggest concerns I hear about UBI is where the money comes from. I think think your point about eliminating the welfare state systems is a big part of the solution. Think of all the bureaucratic cruft that exists right now and how many of those resources could be diverted into more impactful areas such as paying for UBI that enables more to participate in the economic flow of goods and services. It's easier said than done, but I think a lot of the UBI's implementation costs could be covered by consolidating expensive and complicated systems into a simpler solution like UBI.