DockYard’s Phoenix Phrenzy

To highlight the capabilities of Phoenix LiveView, DockYard created and is running Phoenix Phrenzy, a contest for developers to build with Phoenix LiveView. The voting period ends on October 20, 2019, 5pm EDT. Anyone with a GitHub account may register and vote.

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).

Focus

“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.”

Harvey Dorfman

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 Praise of Rails REST, MVC and Conventions

Guiding Principles

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.

Rails Rumble 2013: “Phaser Beam” Wireframing

wire frameLow-Fidelity Pencil Wireframes

Wireframing is a common and time-tested tool to hash out app details. Yet for hackathon efforts such as Rails Rumble, this planning step is often skipped. When you’re thinking of knocking out code as quickly as you can, any form of “documentation” seems cumbersome.  Here are a couple reasons teams should wireframe ahead of time.

Wireframe to plan.

“Plan, don’t create” is how the organizers describe what is allowed prior to the 48-hour competition phase. Wireframes result in a nice visualization of chunks of work to be planned and prioritized.

Wireframe to define scope and vision.

Teams that do not walk through their app ahead of time will find team members arrive on Rumble day with different visions which need reconciled. Without consensus on up front, too much time is wasted discussing and debating. Wireframes are a great tool arrive at a shared vision prior to the Rumble.

Use whatever tools work for you (we use pencil and paper).

Though digital mockups are allowed, pencil and paper are the easiest way to iterate through ideas. The classic cathartic act of crumpling up discarded ideas and tossing them across the room can’t be replicated by digital tools. For this and other reasons we like pencil and paper. We use my grade-schooler’s algebra graph paper. For other alternatives, here are sites with ready-to-print sketch sheets.

http://zurb.com/playground/responsive-sketchsheets

http://konigi.com/tools/graph-paper

All of that said, let me say that I write this mostly to share our approach. Other years we have more-or-less winged it. This year we’re trying a little more up-front planning. Yet what it really comes down to is this:

Wireframe or not. Plan ahead or “wing-it!”.

It doesn’t really matter as long as you Have Fun!

(I just happen to think you’ll have more fun if you plan ahead.)

Rails Rumble 2013: Team Phaser Beam!

We have a Team!

Last year my entire family participated in the Rails Rumble. We built a garage sale app called MayMySales and had a fun time doing it!

In 2008 (“BidBuildBill”) and 2009 (“AffiliApp”), I entered solo. Having a team is much more fun than going solo for 48 hours. So, in the spirit of last year’s fun, we’re doing it again for Rails Rumble 2013!

Here are the stats on this year’s team.

Team Name: Phaser Beam
Team Members:
    Scott M. – Age 44
    Jonathan M. – Age 15
    Rachel M. – Age 11
    Shannon K. – Age ?
Mascot: Zanna the dog
App Idea: [redacted]
Favorite donut: Krispy Kreme

We have a Designer!

One member of our team, Shannon, is a talented graphic artist/designer. (She is also my niece – nicely continuing the family approach.) I’m convinced that a nice looking app is one key to judging success and am very happy to have a pro on our team!

Let’s Rumble!

Look out for team Phaser Beam. We are ready to Rumble. We invite you to follow along.

Launch with Bugs

37signals is the poster-child for recurring-revenue SaaS apps. They have several blockbuster successes, most notably Basecamp. The newest version of Basecamp launched in 2012. How many bugs do you think 37signals fixed in the first three months after launch? Take a guess. I’ll wait.

Did you say zero? Buzzz. Way wrong. Did you say less than ten? Buzz. Wrong again. Did you say less than one hundred? Sorry, wrong again. basecamp.com/changes lists 116 “bug fix” related changes to Basecamp in the first three months after launch. To all software developers, that is not surprising. There’s no such thing as bug-free software. But to too many small SaaS startup owners, knowing that there were a 100+ “bugs” out there would prevent launch. Don’t let it! Even with bugs, just launch that baby already.

discuss
twitter

Simplify 7 – Don’t Commute

Today I drove to work. To drive to work is seemingly un-remarkable except that every other day my commute consists of walking down the stairs to my office, pictured here.

Today the CEO was in town so I drove ninety minutes each way to my employer’s offices to meet, hear strategy, and have lunch.

It was a good day. It was good to meet team mates in person. But I did not enjoy the drive.

I don’t mind a good drive. I enjoy driving the curves of mountain roads and the straight, sunlit pavement of rural counties. But driving to and from work is something I cannot recommend. The benefits of a no-commute job are many.

Save Time
The average daily commute time in the United States is almost 50 minutes. At 22 work-days per month that’s over 18 hours commuting. That’s 220 hours a year, which is over a month of work days. Think about it. What could you do with an extra work-month in a year, every year? Or even better, what could you do with an extra month off each year?

Save Money
For the last five years, we have been a one-car family. Compared to the norm of two, or even three-cars – we have at least one less insurance payment, set of mechanics’ bills, car payment, and gas tank to fill. Even if you have multiple cars, you can save hundreds of dollars a month in gas and wear-and-tear by keeping it at home when you work.

Save the Earth
Whether by car, bus, or train; the further and longer your commute, the more it pollutes.

Save Your Sanity
Maybe the search for more simplicity and less stress is my mid-life crisis. Whatever it is, I’ve become convinced that there is no amount of money, prestige, or other worldly reward worth purposefully adding stress to your life. Life’s too short and the days too few to have any one of them stained by stress.

Shorten or eliminate your commute to save time, save money, save the environment, and save your sanity. I, for one, expect to always work at home or in a place to where I can walk or ride my bike.