Here is my 2019 annual review (h/t to the Full Focus Planner Quarterly Preview.)

What will you keep doing?

In 2020, I will continue to…

• Use the Full Focus Planner (FFP) in 1Q 2020
• Plan today’s tasks toward goals in FFP
• Make time for family and friends
• Move, stand and exercise daily
• Go to the gym daily
• Go to church
• Take notes
• Journal

What will you improve?

In 2020, I will improve on the above by starting to…

• Limit FFP goals & habits (more on goals vs. habits later) to 2 / quarter
• Use Things 3 for task management outside of my FFP daily big 3
• Call Mom & Dad more often
• Track calories daily (healthy body’s made in the kitchen)
• Add swimming to my gym workouts
• Reading One-Year Bible daily
• Review my notes weekly
• Journal as part of ritual

What will you start doing?

In 2020, I will start to…

• Create by blogging daily.
• Focus on system and habits.
• Look people in the eye when talking.
• Spend at least an hour/day in CIO mode.
• Consistently and proactively use time blocks.

What will you stop doing?

In 2020, I will stop…

• consuming
• being distracted
• creating so many “goals” and deadlines
• jumping immediately to coding solutions vs. managing

Did you know with two commands you can add a new feature to your Phoenix app? Phoenix code generators – also known as scaffolding – create a skeleton of code upon which your programming work can be performed.

In a previous article, we installed Elixir Phoenix in our local development environment and created an empty Phoenix application. This article builds on that previous article, so if you do not yet have an empty Phoenix application running, see that article first.

In this article, we will add something useful to that application.

HTML Generator

The Phoenix generator that creates controller, views, and context for a web app is:

mix phx.gen html 

This generator is perfect for our html-based todo list and is fully documented here. In a future article I will explain each of the items created with the scaffold in context of the Elixir Phoenix request and response cycle.

However, for now, I think it’s important – and fun – to get something running! Let’s do it!

ToDos

We would like each of our ToDos to have the following:

• a name
• room for notes 
• a completion due date
• a completion checkbox

Each of these attributes can be sent into the html generator. In your console, go to the directory where your starter Phoenix app lives and type the following (bold lines are to be entered. Non-bold likes are the output from Phoenix as a result of entering the command.)

$ mix phx.gen.html Todos Todo todos name:string notes:text due_date:date completed:boolean
* creating lib/demo_web/controllers/todo_controller.ex
* creating lib/demo_web/templates/todo/edit.html.eex
…

Phoenix and Elixir in general is great at providing useful feedback in response to commands. In this case, the html generator tells us the next steps to run, so do those next steps now.

Add the resource to your browser scope in lib/demo_web/router.ex:

    resources “/todos”, TodoController

Your file lib/demo_web/router.ex should now look like this.

Run the database migrations which will update your database.

$ mix ecto.migrate
08:50:09.425 [info]  == Running 20191025144448 Demo.Repo.Migrations.CreateTodos.change/0 forward
08:50:09.427 [info]  create table todos
08:50:09.433 [info]  == Migrated 20191025144448 in 0.0s

Run the App!

Start up your app with the following command.

$ mix phx.server

and see the todo list running in your browser at http://localhost:4000/todos!

(Note the url for todos is http://localhost:4000/todos. When starting up the Phoenix server, it will point you to the homepage of the app – http://localhost:4000/. Add /todos to the end to reach the todos page.)

In a future article we’ll dive into the controller, views, and context files that this generator created. For now, create some todos in your new app including one to remember to check back here later for more details!

Prerequisites

This article assumes you have some dependencies installed on your machine. Here is a useful list of references for getting each dependency installed.

Database: PostgreSQL

Most Phoenix projects as well as this series of articles will use the PostgreSQL database. Downloads and instructions for installing PostgreSQL are found on the download page of the PostgreSQL project.

JavaScript Runtime: Node.js

Phoenix uses the Node.js JavaScript runtime.  Downloads and instructions for installing Node.js are found on the project’s downloads page.

Language and Virtual Machine: Elixir and Erlang

Phoenix is written in Elixir. Elixir compiles to the Erlang virtual machine. Installation instructions for Elixir (which will usually also install Erlang) are found on the Installing Elixir page of the Elixir language project. Follow the installation instructions using the installer for your environment. 

Finally, Phoenix!

Install Phoenix like so:

$ mix archive.install hex phx_new 1.4.10

Checkpoint

Before continuing forward, confirm that Phoenix and its dependencies are installed.  

You should be able run the version flag (-v) like so:

$ mix phx.new -v

This should return the version of Phoenix currently installed.

Phoenix v1.4.10

If you get any errors, exceptions or other messages, take a look through the Phoenix installation guide for additional instructions and troubleshooting tips. If you still have any questions or issues, feel free to reach out to me!

Creating the Phoenix Application!

Earlier, we used “mix” to install Phoenix as well as to create our Phoenix project. mix is Elixir’s command-line build tool which is used for almost all steps of creating and managing an Elixir project. We will use mix extensively throughout this series, including now. Let’s create our Phoenix app! 

As this application will eventually demonstrate how to accomplish a wide variety of tasks in Phoenix and become our demo app, let’s name it Demo.

Create with phx.new

1. Create and/or move to a directory in your environment where you would like the project source code to live. It can be anywhere, for me it’s:

MacBookPro:~ smeade$ cd Projects
/Users/smeade/Projects

2. From that directory, enter the phx.new mix command.

$ mix phx.new demo
* creating demo/config/config.exs
….
Fetch and install dependencies? [Yn] Y

3. When prompted to Fetch and install dependencies? [Yn], answer Y.

4. After the mix task completes, follow the next steps:

$ cd demo

5. Configure your database in config/dev.exs and run:

$ mix ecto.create

Note: If you run ecto.create you might see this error:

** (Mix) The database for Demo.Repo couldn’t be created: ERROR 42501 (insufficient_privilege) permission denied to create database

When a phoenix project is first generated, the database configuration (in the file dev.exs) looks like this:

# found in dev.exs
# Configure your database
config :demo, Demo.Repo,
  username: "postgres",
  password: "postgres",
  database: "demo_dev",
  hostname: "localhost",
  show_sensitive_data_on_connection_error: true,
  pool_size: 10

If you do not have a PostgreSQL user of postgres with password postgres, you will need to change this configuration to credentials that are available on your local database environment. For example, I have a user “phx” with password “phx”, so I update my dev.exs file like so:

# found in dev.exs
# Configure your database
config :demo, Demo.Repo,
  username: "phx",
  password: "phx",
  database: "demo_dev",
  hostname: "localhost",
  show_sensitive_data_on_connection_error: true,
  pool_size: 10

6. Start your Phoenix app with:

$ mix phx.server

Open the App!

Now you should be able to open your browser to http://localhost:4000 and see the “Welcome to Phoenix!” screen!

I’m happy to help out if anything in this article is unclear or not working for you. Reach out to me at https://twitter.com/smeade

Thanks for reading. In a following article, we’ll create our first “Hello World!” page.

Looking at the six dimensions of wellbeing: physical, emotional, social, cognitive, spiritual, and environmental, Stulberg identifies a couple key points and behaviors for each which research shows can improve our health, well-being and lifespan. Follow the findings summarized in the article and you’ll have covered 80+% of what we humans should do to help keep ourselves well.

Having too many apps, tools, books, podcasts, videos, conferences, talks and processes leads to too much effort spent selecting tools, planning, procrastinating and pre-optimizing instead of doing. This is true for wellness and also most other areas of modern life including business, religion, learning, hobbies…

So yes, it is perhaps paradoxical to have copied quotes from the article into a checklist. However it is at least an actionable checklist. Here is a printable pdf of actionable quotes from the article. Follow Stulberg’s research-backed advice and you’re on your way.

Educators and people that work daily with children and in servant-leadership roles understand and practice these observations almost innately. However those of us in tech, especially remote tech-workers, could use a reminder.

Passion and Purpose

The event space was filled with passion. Passion for PAA was evident in the students that spoke and performed, the parents of those students, the supporters and the staff including Production and Site Manager, Sam Leahy and the Executive Director, Dr. James Ramsey. However, the most palpable passion was not for performance of music or theater or arts. The most palpable passion was for the impact that PAA has had on individual people’s’ lives. 

Dr. Ramsey used his time not to talk up the numbers or financials or growth rates, but to instead share a story of one child who was in a production being hosted at a school. This student was restless, lacked focus and had a difficult time keeping his hands to himself. The student did not seem to want to be in the production and acted as if he expected to be kicked out.

Upon speaking with the student’s mom, the staffed learned he did in fact very much want to be there and she asked if PAA could somehow help make it happen. Dr. Ramsey and his staff took the time to personally meet with the school staff and the mom. They learned more about the student’s background and desires, spoke with him to set expectations and found a place in the show that would work for him. Dr. Ramsey personally checked in with the student every rehearsal. The student was able to participate and gained a new sense of confidence and well-being. He simply needed to know that there were adults in his life that cared and listened and expected him to be able to excel. 

The many hours and extra effort spent working with this one child had little to do with musicianship or acting skills. It had everything to do with listening and being noticed and setting expectations creating an impact much larger than arts instruction itself. Leaders often think primarily of their and their team’s technical skills, however a leader’s purpose is well beyond that.

Dr. Ramsey and the staff of PAA have a passion for performance. However their purpose is to leverage that passion into positive impact beyond themselves. 

Growth and Purpose

That one kid didn’t directly matter when it came to the program’s growth. That one student’s experience was not going to result in X number of new students signing up the next season. Dr. Ramsey and Sam Leahy spent time with that one kid because of their sense of purpose.

The thing is though that the program has grown precisely because of they ways they work with students one at a time, where they are and with who they are. When students talk of PAA, they don’t talk about musicianship or artistry. They talk about confidence, friendships and intangibles that will be with them for a lifetime. The community’s desire for these intangibles is manifest in PAA’s growth.

Considering one definition of purpose is a “sense of direction, core values, and connection with something beyond yourself” here are some thoughts not often exhibited in the tech bubble.

1. Growth with purpose takes time, sometimes years sometimes decades.
2. While leaders love dashboards and scoreboards, a fulfilled sense of purpose is not measurable. In our growth-for-growth’s sake industry it’s so easy – for the tech community especially – to turn everything into metrics, processes and A/B tests. This in itself is not bad. It becomes bad when we forget that a healthy definition of purpose includes a connection with something beyond yourself and is likely not measured by streaks, apps or likes.
3. You may be a musician or a software developer or an executive leader, however that is not your purpose. Your purpose is what you do with your musicianship or your software development skills or your leadership experience. 

Metrics, processes and A/B tests can be useful for running a company and organizations do require positive cash-flow to remain in operation. However let’s not pretend that the metrics, processes and A/B testing that identify people as users or which rank them by their customer lifetime value have a purpose beyond profit.

Sometimes it takes jumping out of the tech and startup bubble to be reminded of this more healthy vision of purpose.

Source code for each submission is currently publicly visible. This provides us a great opportunity to see the implementation details of deployed LiveView apps. The submissions can be clustered into a few categories.

Games (18): Tetris Kachori, LiveView Tetris, Space Birds, Unox, crack the cregg, Archmagi, Phoenix Royale, Demon Spirit, Ground Control to Major Tom, Never lose Tic Tac Toe, Geo Racer, Answercast, Roll & Music together, ETE, Pentomino Game, Live Chess, Live View Math, CodeBreaker!
Data (4): Visualixir, Fprefs, SimpleBet MLB Pitch-By-Pitch Viz, Pie Chart Maker
Business/Productivity (4): Elixcel, Pomodoro Timer, Kanban LIVE!, 
Writing and Drawing (4): Haiku Live, LiveDraw, TypoPaint, LiveView PixelArt Editor
Utilities (4): gluster-dashboard, Elixir Console Live, Phoenix Commander, Elixir Regex
Music (2): MIDI LiveView Demo, LiveTracker
Other (2): Baby Age Calculator, Flame of Life

Some of the submissions caught my attention. I’m certain the other entries also do a good job of highlighting the power of LiveView and are worthy of your time. Here are a few that happened to catch my eye.

Elixcel

by Jørgen Orehøj Erichsen
https://elixcel.onrender.com
repo

This entry caught my eye with its simplicity and visual appeal that lets you easily understand what the app does with just a short gif. Elixcel is narrowly focussed on LiveView functionality (this is a LiveView contest afterall), yet I was impressed by its thoroughness. The author didn’t just stop at entering cell values and making basic calculations (though that would have been illustrative enough of the LiveView use case). Instead he added keyboard support for: arrow key navigation, bold/italics, cancel via esc, delete via backspace, etc. as well as add-row and add-column buttons in less than 400 lines of code.

Good job @joerichsen.

CodeBreaker!

by Aravinda VK 
https://codebreaker.gigalixirapp.com
repo

LiveView templates can be rendered inline (via the ~L sigil) or they can be rendered via a separate .leex html template (docs). .leex templates can render and nest standard .eex templates (aka “partials”).

I think the .leex template is more familiar, approachable and maintainable for developers than the embedded approach so I looked through some of the entries to find some that use the .leex html template approach with nested templates. CodeBreaker! is one of those.

Besides being a demonstration of .leex templates, it’s a fun game to play.

Geo Racer

by a small mighty Gaslight team
https://georacer.io/
repo

On the other end of the complexity spectrum, GeoRacer is such an ambitious entry that it just had to have a mention. The scope of the effort is impressive. “The racing game helps you track down waypoints with an interactive hot/cold meter. But beware, your friends will gain hazards along the way that will make your race more difficult. Be the first to collect a courses’s waypoint and win the day!”

This project has a mix of standard controllers and views combined with live views. It goes well beyond LiveView functionality though. The GeoRacer team created Plugs and also uses Channels. It leverages :geo, :geocalc, and :geo_postgis for geo support. There’s an impressive amount of Elixir and Phoenix packed into this project in such a short timeframe. Theres lots beyond LiveView to dig into and learn from the GeoRacer repo.

The Elixir Community and Ecosystem

The PhoenixPhrenzy contest highlights the friendly and supportive nature of the Elixir and Elixir Phoenix community. In tweets, participants talk about their work as fun and enjoyable. When promoting their submissions, app authors do so in a friendly way that is not ego-centric rather humble and encouraging of folks to look at not just their apps but also at the contest and entries in general.

Some of these projects also demonstrate the power of leveraging existing Elixir community packages. For example, Elixcel uses the Abacus parser for mathematical expressions. Developers seem reluctant to use Elixir Phoenix because the ecosystem is not as mature as Ruby’s so the library of packages available is perceived as lacking. Let me assure you that is not the case. Whatever tasks you are working on as an Elixir developer, do not assume you have to write it from scratch. Instead, search hex and you might be surprised. 

Go Take a Look and Vote!

In the time I spent reviewing entries and writing this, another 10+ votes have been cast! If you’re interested in Phoenix LiveView – or just want to see what some folks are building with Elixir and Phoenix, go check it out (requires sign in via GitHub).

“There are two locales in a pitcher’s universe – on the mound and off the mound. When a pitcher is on the mound he [sic] should be thinking about only two things pitch selection and pitch location. If he finds himself thinking about something else, he should get off the mound.”

And so it is with software writers.

There are two locales in the software writer’s universe – in the code and outside the code. When a software writer is in the code they should be thinking about only two things, the line of code they are writing and the domain for which they are writing it. If they find themselves thinking of anything else, they should get out of the code. – sbm

In March, I:

• Avoided posting to Twitter and Facebook.
• Created a habit of ubiquitous capture.
• Created a process habit (inbox 0).

Avoided posting to Twitter and Facebook

Avoiding Twitter and Facebook posts was initially a way to reduce the number of knee-jerk reactionary postings I would make, mostly around politics. Like a lot of Americans, was (and am) frustrated. But the amount of venting I was doing was an indicator that I was granting my frustration too much space in my life.

I was in a cycle: get frustrated about something, immediately desire to vent about it. In order to vent about it; think about it even more to try to build somewhat cognizant thoughts around the topic. Then think about it even more after posting as people reply. In this one, one (sometimes trivial) frustration would become amplified and take up a non-trivial amount of my energy and time.

Avoiding those outlets for frustration has broken the amplification cycle.

Next I want to extend that benefit from an improved state of mind to improved productivity by avoiding reading of social media and news. More about that in the April planning post.

Created a habit of ubiquitous capture

I installed Wunderlist on my phone. Every todo or thought or task or plan, large or small, got captured in one “inbox” list. This list replaced at least three other methods I was using to try to keep track of what needs done. This ubiquitous capture habit replaced my email inboxes, scraps of paper and headspace.

If something needs to be done, I now feel confident that I can set it and forget it. If I have an idea or thought I now feel confident in immediately capturing it and knowing that I will get to it in time.

Knowing that my long list of todos and ideas is in one place has set a foundation for becoming better organized and more productive.

Next, I want to change my capture habit tools from phone to pencil/paper. More on that in a future post.

Created a process habit

Related to ubiquitous capture, I am now in the habit of processing my inboxes (online and physical) to zero. There’s much debate about the inbox zero approach. I won’t rehash it here. For me, it works. A long list of unread emails, a stack of un-processed physical mail, or a emails read but not acted upon all increase anxiety and act as roadblocks to getting big, productive work done.

Now with any “inbox” item I immediately either:

• delete it
• delegate it
• defer it
• archive it

Knowing that todos and ideas have at least been initially processed has reduced anxiety and increased motivation.

Next, I need to take advantage of my reduced anxiety and increased motivation to improve execution – e.g. get stuff actually done. Again, more about next steps on this habit in the next post.

Next steps in April

The habits formed in March do little by themselves to make improve productivity. Instead, their purpose is to clear the plate and lay a foundation for increases in productivity. The freed up time and headspace along with reduced anxiety are necessary to build the habits that will improve productivity.

TL;DR;

In 31 days I created the habits of social media posting avoidance, ubiquitous capture, and inbox processing in order to clear the plate and build a foundation for new productivity habits over the next 30 days.

I’ve been thinking about the “good old days” of Rails development. It seems there was a time where Rails conventions were more closely followed. Perhaps because the community was smaller. Perhaps because developers felt that the Rails conventions supported the smaller apps of the time.

Recalling these simpler days, I’d like to review the simplicity and power of the REST/CRUD combo by offering reminders of some of the well-known benefits of sticking with this convention.

Stick with REST/CRUD

It’s not sexy. (You know what is sexy? Delivering quality code, quickly.)

Compared to alternatives, REST/CRUD is

* Easier to understand
* Easier to maintain
* Easier to test
* Easier to API

Easier to Understand

Remember that the future you or future developers will need to understand the application’s flow and logic. The greater number of custom methods or actions the application has, the harder the code is to understand and follow. Everyone knows what the create action does. Everyone knows where to go to find the code that creates an object. But when code is in a custom add_comment action, it becomes non-obvious where to find the code that creates said comment.

DHH:
Common problem I see in Rails code: Too few controllers. More controllers doing less work obviates need for many other fancy patterns. You can have many controllers all directing a single model but in different contexts. Less if/else, simpler views, simpler actions. This becomes easier to do if you’re militant about only exposing REST CRUD from each controller. Any deviation => new controller. https://twitter.com/dhh/status/453181241127620608

As a side note, a reminder to keep controllers thin.

When code is in controllers the code tends to get very complex, very quickly. Most domain logic should be in models or modules. This reduces the number of “paths” through the application, reduces the number of interface points between the client and server, and reduces the number of places where code must be maintained and troubleshooting occur.

Easier to Maintain

When building Ruby on Rails, MVC, database-backed, web-apps, use the power of Ruby objects, ActiveRecord, and friends. When you think that ActiveRecord will not be up to the task for your special case; give it a try anyway. You will be surprised at AR’s performance and at the speed at which you can develop.

Easier to Test

The more that code follows convention and uses Rails as-is, out-of-the-box; the fewer tests need written. Remember: “don’t test the framework”. You could end up with entire controllers and even small models which require no or very minimal tests.

Easier to Expose an API

Rails gives applications a REST API basically for free.

In general: Be Thoughtful in Design

Programmers who know nothing about object-orientated design can be very successful in Ruby. However, successful but _undesigned_ applications carry the seeds of their own destruction; they are easy to write but gradually become impossible to change.

– Sandi Metz , “Practical Object-Oriented Design in Ruby”

Be vigilant, thoughtful, purposeful in design. Stick to convention and may that day when your application becomes impossible to change never come.