Have you read Part 8 of the Making a Side Project series?
Photo by Ryan Riggins on Unsplash
Before we into the weeds of the development for Deaton, I’m going to share my local development setup and a little more about my development process.
For the last 15 years I’ve been building Apple hardware. Most recently on a 15" Retina Mac Book Pro 2015 edition. It’s a great laptop. I’m not thrilled by the changes to the latest edition, and will probably switch hardware the next time I need a new laptop.
I’m not in love with the idea of going back to Windows, so Linux of some variety is in my future. If anyone wants to send me a laptop to review, I love to get my hands on and try things before I buy, that would be great.
I do all my development inside of a virtual machine of some kind. For Laravel sites all inside of Homestead.
Laravel Homestead is an official, pre-packaged Vagrant box that provides you a wonderful development environment without requiring you to install PHP, a web server, and any other server software on your local machine. No more worrying about messing up your operating system! Vagrant boxes are completely disposable. If something goes wrong, you can destroy and re-create the box in minutes!
No more fiddling around installing a webserver, installing php, installing a database server any other server software directly on your laptop. Just get Homestead up and running and you’ve got a purpose built environment. This is one of the reasons I’m less worried about moving away from a Mac to Linux.
Since I also use Forge for hosting most of my projects, this means my local development environment is very close to the final production environment. This means less problems are likely to popup when you deploy your code to production.
I’ve been using dev as my local TLD, so as I build Deaton locally I’ll access it via http://deaton.dev. Unfortunately the dev TLD is actually owned by Google may be used for real in the future, so I’ll probably be switching to localhost as the TLD for all my development sites. localhost, test, invalid and example are all reserved TLDs so you can pick one that you like if you prefer.
I’ve been using the Sublime Text editor since late 2009. I’ve tried many other editors and IDE’s, and while they have some nice features, I’ve always comeback to Sublime Text. The speed is what has me hooked.
Opening files, switching between files, searching in files is lightening fast. As an extreme example, once I launched Sublime, opened a project, opened a file, fixed a simple bug, in less time it took to started a fully featured IDE. It also has no problem working with big files, really big files.
If you’re interested in other editors, a couple of great options are Atom, and VS Code.
Although it’s not required, you’ll find yourself connecting to the your database often. Whether it’s to quickly add some test data, or to check the structure of a table, using the command line can be a headache.
My favorite database management tool is Sequel Pro. Sequel Pro is free, open source and built specifically for MySQL database servers. It has a native macOS interface is very easy to use.
When I’m working with a Postgres database, I’ve ben using Postico. It’s not nearly as polished at Sequel Pro, but it gets the job done.
If you’re on a Windows machines, give HeidiSQL a look, works great for MySQL and Postgres databases. I haven’t tried it yet, but have heard good things about DBeaver for Linux.
I run iTerm2 instead of the built in terminal on macOS, and setup Oh My Zsh for my shell. It has some great features that make working in the command line much easier.
Options are little limited on Windows, but as long as you can ssh into the Homestead server, you’ll have a Linux machine to run your commands on.
Like the rest of the world I use Git for all my version control. Although, I’ve used Github and Bitbucket most recently I’ve been hosting my repositories on Gitlab. The 3 services are pretty similar in terms of features now, although Github was a real pioneer here.
Since I have a large number of private repositories, Gitlab is the best for me due to its pricing. I use Gitlab for free.
There is no one way to build software, its changes often for me, depending on the project and the team I’m on. I do usually approach the build in the following way, for Laravel based web applications.
For each feature I usually begin with the routes. This is the entry point for the application, and is formed by looking at the sitemap. I write the routes for each page and action.
What information is needed to build this feature, I write the migration need to create new tables, or add columns to existing tables.
Next come the controllers. The controllers and methods required are defined in the routes.
For the more complicated actions I’ll typically write some pseudo code that outlines the functionality we need, as a comment in the function. I’ll then breakdown and write the actual code in the controller, or move it to the models or helper classes as appropriate.
Finally come the views. All the HTML, CSS, and JS required to show and collect information from the user.
The majority of my sites are built with the Bootstrap framework, some with JQuery and some with VueJS. All are responsive.
Blasphemy for some people, but most of my side projects I don’t write tests. Testing is an important part of software development, but takes time. Time I don’t have.
Once a project moves out of the side project phase, and the developer has real time to devote to the project, with a clearer set of requirements and a detailed product roadmap, then tests should be written.
If you’re interested in learning how to code with Laravel, I recommend watching all the videos on Laracasts.
—
