Pick Good Tools For Yourself
Given the choice, pick tools that work for you. Ask yourself, "Will this make it easier for me to make good software"? What is your situation? What are you building and why? For point of reference, here is my thought process for picking tools.
The Front End
HTML and Javascript are givens for web applications. Since I'm not a web designer, Bootstrap makes it easier to put together interfaces that work on a 22 inch monitor and Android phone.
Usually, my project is some kind of single page application. At the time the decision was made, AngularJS looked right for this. That might change some time in the future but, for now, it's the Javascript resource I know best.
Middle Pieces
Choices of middleware were informed by my Python 3 biases. Flask and SQLAlchemy are the two major pieces as libraries go. Flask makes creating JSON-based web APIs easy. SQLAlchemy let's me use a database toolkit without being forced to use an ORM.
As application and web servers go, googling around and asking questions on Reddit helped me decide. That's how uWSGI and Nginx ended up in the picture. uWSGI handles my Flask stuff. Nginx plays proxy to Flask and static files.
Back End Parts
MySQL on an Ubuntu server is something I know so I stuck with it. The rest of the pieces of my stack fit naturally in that context. It's easy to find help online if stuck. These were easy choices.
Working a custom tech stack generally requires a custom server setup. Virtualization and cloud environments make sense here. On the development side, Vagrant and Virtualbox do the job easily. For production, Digital Ocean is a cheap no-frills service for setting up a Linux server.
For deployment, my pick is Ansible. Knowledge of YAML plus native provisioning support in Vagrant swayed me on this one. Ansible uses an idea called playbooks. Playbooks used to provision a virtual machine can also work on a production server with little to no changes.
For deployment, my pick is Ansible. Knowledge of YAML plus native provisioning support in Vagrant swayed me on this one. Ansible uses an idea called playbooks. Playbooks used to provision a virtual machine can also work on a production server with little to no changes.
And that's how my tools were chosen. I went with what made the most sense and asked for input when in doubt.
The Acronym
By the way, if you do pick the same tools that I do, you can make a nice acronym out of it!
FUMBLINA = Flask uWSGI MySQL Bootstrap Linux Nginx AngularJS
I made that up myself. Kind of proud of it!
The Small and Silly Fumblina Philosophy
Here's the thing. A full stack developer is not an unstoppable force ready to tackle any large project thrown her way. She is not the developer equivalent of this guy.
Mr. "Full Stack" I presume?
Below is a better way of thinking about what "full stack" means.
Being A Part Of Your User Base
The best kind of product to be working on is one where you are one of the users. For example, I am the sole user of Learning Machine. A big user base isn't the goal. I want to make things easier for myself when it comes to learning new things. There are tools to build that help me in that regard. If a user base ever did happen, great! Having a head start as "User 0" puts me in a better position of understanding their needs.
Keeping the Feature Set Small
My favorite explanation of the "Minimal Viable Product" concept comes from Extra Credits, a Youtube show about game design. The video emphasizes that a new game should start out with nothing but the absolute core mechanics and nothing more. This is what you want to get right before adding all the supporting attributes.
In a recent round of commits on my Learning Machine project, everything was stripped out except for three things.
- Making practice exercises.
- Quizzing and rating yourself on existing exercises.
- Reviewing a report to see where you're doing well and where you aren't.
Focusing on the core essence of a project is crucial because, as a full stack developer, there are limits to what one can do. A full stack project for something small is challenging. One with a huge feature set is going to spread you incredibly thin. That's not a good thing.
Not Taking Yourself Too Seriously
Fumblina is a funny-sounding name. It's the kind of name you give to a fairy with a lazy eye who can't quite fly straight. When calling myself a Fumblina developer, I'm aware that I'm making fun of myself. Laughing at oneself is a good thing and more people should do that.
Any "serious" full stack developer will have her share of stressful moments. A sense of humor relieves stress. Less stress leads to better judgment calls. Better judgment calls are more likely to lead to the ultimate success of a project.
And that's the whole Fumblina philosophy. Or at least, that's how I like to think of it.
No comments:
Post a Comment