I was in the middle of a conversation with a friend the other week and we started debating some data access nonsense. This friend (whom shall remain anonymous) asked me a simple question:
I am a software developer living in Seattle. I specialize in web development but I am currently shifting my focus a bit towards backend systems and databases. I host and produce the podcast This Developer's Life with my friend Scott Hanselman.
I was in the middle of a conversation with a friend the other week and we started debating some data access nonsense. This friend (whom shall remain anonymous) asked me a simple question:
I'm headed out on my own once again, and no, there's no drama here. Pluralsight has decided to venture into a realm of training that I'm just not qualified for (enterprise) so they were good enough to let me go off and do my own thing again.
Before I get to the meat of this post, the code for what I've written so far is up here. The main bits are in /apps/peach.
Migrations are a simple mechanism whereby you script out some change commands for your ORM, and that ORM then builds your database for you. To me, this is pure insanity. I dislike ORMs (accept, of course, for LLBLGenPro, which is astoundingly good). Trusting your ORM to build a proper database is ... kind of weird to me. SQL is terser, more expressive and (as it turns out) just right for the job.
I was asked a great question on Slack the other day - I wish I could remember the person's name (sorry!) but I can't find it ... anyway they asked me (paraphrased):
Let's implement an intelligent shopping cart - something that tracks what the customer is doing, how they came to our store, etc. I tend to think of these things in terms of a "Session" - a shopping process where a customer selects things, puts them back, and eventually (hopefully) buys something. If I do things correctly (to me, at least), I should end up with tight little functions an exactly 0 if statements.
When you build applications in the Erlang world you create discrete processes that interact. In theory this is pretty straightforward - until you actually try to do it. Microservices fans out there know the value (and the pain) of managing a fleet of services; there are benefits to it, definitely, and also problems.
As CTO I get to call the shots here at Red:4 but I do have to answer to the CEO and others. It's easy to arm-wave, to go on and on about Elixir and functional languages - but at the end of the day it's what you do, not what you say that counts.
I like building things and sharing my experiences. I've mostly focused on the web, but of late I've moved a bit more towards back-end systems and databases. I also love working with Audio/Video.
I think sharing what you do is incredibly important; equally as important is to make sure you never posture as an expert unless you truly are.
