Stephen Bussey wrote a book that explains how to use the Phoenix Web framework to create real-time applications. The basic building blocks, presented early on, are the Phoenix concepts of Channel and Socket. The Socket is responsible for connection handling, while Channels allow users to subscribe to named flows of informations and be updated on changes they are interested in.
After introducing the main tools for the job, the book has a large central part that shows the development of an application that meets the real-time requirements (in a nutshell: the user sees changes without having to refresh the browser). These are clear and easy to follow. For the few times I've got stuck, I could compare my code with the codebase that Stephen made available for download.
A third part is a treatment of ways to deploy real-time applications. This was of limited interest to me as I'm not involved directly in this phase of the life cycle, but it was very interesting to know what is going on at the far end of it (and you never know when you need to deploy your own project).
The last part is an overview of what you can do on the front-end side of things, with a chapter that uses React (not bad) and one on LiveView, a promising front-end technology that allows us to use Elixir to write most of the UI and only relying on a relatively small fragment of ECMAScript.
I find the subject quite advanced for my current level but sure it offered a detailed and interesting treatment of the subject. Recommended if you touch applications written in this techonology.
I didn't establish OKRs (and didn't update the Now page), so this will be a quick recap.
I've finished reading Real-Time Phoenix by Stephen Bussey and practiced a lot during and thanks to the Advent of Code 2020. I'm not exactly proud of the code I've written but it's been very useful in finding out about many unfamiliar concepts.
I've done flashcards almost daily and tried to keep doing three 30-minutes study sessions on Keeleklikk. I can't complain
I haven't run much this quarter but I plan to get back during the next one.
Here's how the quarter went.
This OKR has been frustrating and not very rewarding. It has changed shape a few times and the observable result of it might just be a few more lines of documentation in Confluence. I have learned a bit more about care-taking, the name we give to the activity of the one team member that each week, in a rotation, fields questions and maintains the systems' health while the rest of the team pushes on the development.
The book Elixir in Action never reached my desk. Not the best of the excuses, but not the worst. Halfway through the quarter I started meeting once a week with other readers of Real-Time Phoenix, which has been motivating and fruitful. It is a very hard book though and we're still on chapter 5 (and personally I'm on chapter 6), but there are 19 chapters in the book. I'm not even sure if it's realistic to expect this done by the end of the year, but I'll try to set a realistic goal for myself to do at least 6 more chapters or so.
The plug's is a sad story. There's a task in our board but I haven't been allowed to tackle it. Simple as that. I need to find time on my own to actually push on this goal.
I haven't been very constant but I'm happy with where I've gotten. I'll pace it better next quarter.
I could've been more ambitious with this OKR, but I'm very happy with it. I'll see what I can get done with the next one, when the weather will start to get rough.
I haven't worked much on this. To my partial excuse, I've been on the lookout for new opportunities. I've found one for an Elixir Plug to write for work (I'll work on it at the end of the quarter).
I want to push on this and start some side project, but I have utterly failed so far. Will push this one more in the next iteration.
A curious finding: I'm in a list of top contributors to FOSS in Estonia.
This one is working well. My current stats:
It's true that it's almost 2 months, but this is really a long-term objective. But what's unprecedented for me is the care and attention to the detail I'm developing just because I know I'm in a safe environment where all questions can be asked and curiosity and learning are always rewarded.
This one is tricky, but it's starting to work. I'm still too tired at the end of the day to dedicate energies to side-projects, but I have broached the subject of an Open Source initiative in the company and my coach encouraged me. Also a long-term objective, but concretely I have been pointed to a possible telemetry library that can be started already as a FOSS project. Will need more work.
I consider this one achieved!
It was pretty cool. The end result looks very amateurish but I'm pretty proud for trying something totally new and bring it to some sort of completion.
I haven't decided yet whether or not I'll go on playing with it, but I admit that my enthusiasm has faded. I'll take some time to think about it.
Not started. Will I ever start it? I gave myself a few months, and only one has passed. But as said above, my enthusiasm has declined. I'll think about it.
I've done a lot before starting the new job, but now I see this as marginal as I saw it before. I recognize its important, but I just can't see how to fit it in my schedule -- especially if it needs to steal time from side-projects and experiments.
To practice a bit with React and Node.js, not long ago I've started writing a small application with the tentative name of Budgeter. It's been a serious attempt at starting something and consider it finished. I've learned a few things and I want to start writing about them in a series of posts.
Here's a tentative, rough layout of what I want to talk about. Some of them are strictly technical, but at least one is more philosophical and deals with the definition of "done" and its approximation.
Random factoid: I'd logged 27 hours and 30' when I considered the first milestone completed and put the project in the open
The repository is available on GitHub.
In this post, I want to detail some of the criteria that have helped me pull through the effort of creating a small budgeting application. I also mean to explain why it's called Budgeter here, but
capital on GitHub, and about the benefit of inconsistencies and how this is related to The King's Speech.
I like reporting, and I do it in several domains. One of them is budgeting. I use a spreadsheet to note down the expenses I have each month and try to separate them into categories, so I know that a given month I've spent, say, 100 euros in restaurants. I like to see trends and to take action in case something is not going according to the plans.
In the spirit of learning, and since I love to have side projects, I started writing an application to do the exact same thing.
I don't need to school you on the benefits of reinventing the wheel1 : you get to pick whatever technology you want to understand better, and try to develop a small product, so you understand what type of choices go into making it.
This is what I set up to:
I want an app that allows me to report expenses. I should be able to add an expense, inserting date, amount, category, and a small description. The app should be able to show some reporting on them.
Easy. How do we go about it?
I wanted to try React. I've used it in the past but never brought a project to completion (if you disregard, like I do, the output of video courses). What goes into bringing it up until you start writing a line of code is the subject of another post; here I only want to say something about the scope and the lessons learned.
For any feature you can think of, there are many ways of making it better, or more thorough, or more visually pleasing. The first thing you need is focus. The second thing you need is a plan with priorities, and a way of making sure that you are focusing on something important.
I don't like making plans a lot in advance, before I even know whether or not I'll be working on something for a few weeks. So I started writing code to achieve the few goals I stated above. After the first week, I started moving the biggest TODO/FIXME notes I had been sprinkling in the source code to create GitHub issues. I grouped them into Milestones and decided that before making this project public, I wanted some things fixed.
To stay focused, I use short timers usually called pomodoros. I set a timer for 15 minutes and try to do one thing only2. At the end of the 15 minutes, I try to think if I'm focusing on the most important thing to do; if so, I set another one.
Resist the temptation of working on something else, especially if it's another bug that you'd rather fix now.
I found myself drifting away from the reporting functionality in order to make the
node_modules a single directory shared by client and server, rather than two separate ones. It's a secondary issue, yet I wanted it solved because it bothered me. Don't do that. Fixing the double
node_modules directory was relatively easy... locally. Later I found out I had screwed up the Heroku deployment.
Another example of minor issue: I wanted to have a project with a clear, unique name. I thought of the not so original
Budgeter, but it was used somewhere else, so I needed to call the project
capital on GitHub. I'm not sure how long it takes to fix this inconsistency. I only know that it's not a big deal, and I'd rather write this blog post than dedicate any time to that.
However, there's an exception: Consider working on less important issues if you're bored or stuck and need some virtual fresh air.
Your life is not a dictatorship and you can digress and not follow your own rules from time to time.
Refactoring is sometimes a minion of complexity.
Don't get me wrong: refactoring is a noble activity. It becomes a problem when you let it take all your time.
It's attractive because many times you don't need great focus to do it. When you're tired, taking the logic out of an Express route and putting it in its own middleware seems very important. But you can forfeit it to a later time. This is extremely important if your daily time budget for your project is, e.g., around 1 hour.
Don't let the small things distract you from the big ones.
I set myself a deadline. If you don't, you risk of going on forever until the app is perfect.
Pro tip: It never will.
Just list the features that you want to see, prioritize them, and work on them. The deadline is too close and you underestimated the effort? Enter Scope reduction. Instead of pulling all-nighters, cut the feature to the bare minimum that can be shown to let you say that your software does X.
I wanted the reporting to be way more sophisticated than it ended up being, but I my application didn't allow a user to log out. What comes first? I decided to strip the reporting feature to its essential, postpone the frills for later milestones, and get the logout feature in.
In The King's Speech, the therapist does something interesting to help his patient, the king.
He believes that part of what makes the king nervous is that the act of delivering a speech is seen as too perfect, and the king is afraid of perfection and thus stutters. To reduce this, he suggests that he scribbles over the speech on the paper. Seeing the page tainted helps lowering the tension the patient feels for it and helps him stutter less.
The same happens in software. You want to show something you're not embarrassed of. You want to get the perfect directory structure, never repeat your code, follow all the best practices. All of this is blocking. What you need is:
Put the damn thing out there in the open
And to do that, you need to accept imperfections. You need to be able to say, This is what I have done, given the constraints I had. If I had more time, I'd have done a better job. That's it.
This might make the difference between delivering something and always stopping before the finish line.
Bit of a fuzzy goal, isn't it? I have practiced very little -- I think I've written the only two reviews of this month tonight, and I don't like them. But this objective is clearly coming from me getting a bit complacent. I'll have something more chewy in the next installment.
I've finished this weekend my course on React, left a bit aside as March has been an eventful month (I left my job at Bolt). I'd classify it as a success as yesterday I started to write a little app to manage my budget and I like what is coming out of it. What I enjoy the most is how things seem to come natural and how familiar I feel with the concept of React Component and passing around the state.
I've read a lot in February, also because I've been traveling. Haven't figured how to write good reviews yet, but I want to keep thinking about it.
I think this month I've finally decided I don't want to ever write fiction any more. I've reflected long and hard about this in my private journal and won't report more here, but the gist is that I confuse my passion for reading and stories, even telling stories (in contexts different from writing novels, as in, essays, technical documentation, et cetera), with a passion to imagine fictions. I've tried it, several times, and it's mostly painful. I've come back on this decision so many times during my life that I can't exclude I'll change my mind later.
I have given up a bit on this as I'd like to understand better the technologies that are tangent to the ones I use. Racket is great but I figured that getting on to React might prove more useful in the shorter term. Pluralsight is still my go-to resource for this kind of interest, but I was reading with interest Continue: Web Applications in Racket.