For a few years now I’ve had a small project in mind. I wanted to make a game where you’re on a host computer and need to work out the story by navigating around the filesystem and using Linux applications. Finally this year I started experimenting with a story and came up with the first tiny and short demo for Outpost 73. You can play it in it’s current form via a web browser.
Recently I needed to get to grips with the Laravel PHP framework for a personal project and thought a small tutorial on getting started with the Homestead development environment would be good to help beginners.
Prerequisites You’ll need the following:
macOS or Linux Latest version of Oracle’s VirtualBox Latest version of Vagrant from Hashicorp (optional) Latest version of Composer Installing Homestead Start by installing the Homestead Vagrant box on your machine by running the following command from a shell prompt:
Testing code is important, but can often feel like a burden or task, especially if you have strict deadlines. It doesn’t help if your unsure about what tools to use to implement testing on new parts of a project.
PHPUnit is the gold standard framework for testing PHP projects and there are many testing platforms that work directly with it. While it’s perfect for writing small, composable unit tests it can also work perfectly for integration and functional tests.
Setting email in git commit When you first set up a new dev environment, you’ll want to set the name and email you use for Git commits. The easy way to do this is with two commands:
git config --global user.name "Adam O'Grady" git config --global user.email "email@example.com" This means all future commits in this dev environment will use that name and email address combination.
In some cases you may want to use different details for a particular repo.
Readability, followed by consistency.
The Eternal Arguments Tabs vs spaces Braces on same line or next line camelCase or snake_case variables These are just a few of the positions at the centre of ideological arguments in developer communities that run the gamut of friendly banter to vitriolic ALL CAPS flamewars. Each side has it’s merits and can present solid arguments for it’s use. But all these debates do is cloud the actually important factors behind coding standards.
We all have those personal learning projects that inspire pride in us. Many are our own takes on existing frameworks and tools such as content management systems, math libraries, billing systems, layout frameworks, game engines, etc. Attempting such projects is a vital part of learning to code, picking up new languages or approaching new ways of thinking. I’d be remiss not to encourage people to take on such tasks as a method of improving their skills and a liar if I said I hadn’t done it hundreds of times over myself.
We’ve all heard the term, we’ve all seen spiels about it’s importance, but we also have so many excuses why not to do it. The place I’m currently working at ran into two of the most common reasons I’ve seen and here I document how we overcame them for the benefit of anyone who thinks code review might help (hint: it will) but feels they can’t justify it.
No proper tools Whether the answer is no budget for Crucible or not enough time to set up Phabricator, this is an incredibly common cop out.
For a recent project I realised I would love to be able to set up webhooks for repositories I watch (and don’t administer). So to overcome that I’ve created a Node.js script, WatchedWebhook.
You pass it a GitHub username as a command line argument and it polls the “public received events” feed (including your watched repositories). Any new events that match the event type and repository of rules you specify (in rules.
Woo, finally a new post and a pretty decent occasion to make one, I’ve released a new project! ChernoBravoBB is minimalist forum software designed for ease of access, navigation and utilisation by it’s denizens and carrying an ethos of openness, transparency and pseudonymity. You can check it out on my GitLab where I’m currently hosting the project (might duplicate it to GitHub soon).
It’s based on Node.js with MongoDB backing, utilising the ExpressJS framework (with LocomotiveJS providing better MVC capability) with Jade templating for the views.