Having played around a bit with Gopher lately I decided to take the next step and try and create something more meaningful then test directories and dummy text files. My ultimate goal was to have this personal blog available via Gopher as well and I’m pretty confident that I achieved it. You can visit gopher://gopher.judges119.me and you’ll be able to browse my personal, dev, and ops blogs via the Gopher protocol.
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:
A lot of people talk about JavaScript as an asynchronous, event-driven language but don’t dive further down on what that means or how best to take advantage of it. Even more important is to be wary of the pitfalls that this can involve which I’ll cover in later posts.
The most common asynchronous code you’ll find in JavaScript is usually Ajax (asynchronous JavaScript and XML) requests when dealing with client-side requests, or API calls/database access when dealing with server side systems like Node.
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 "chunkylover53@aol.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.
TL;DR:
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.