pn_net

The following keyboard shortcuts are provided for working with JavaScript.

• C-x C-e – Evaluate the previous JS form and display the result in the minibuffer.
• C-M-x – Evaluate the top-level form around the point and display the result in the minibuffer.
• C-c C-k – Load the current buffer into the skewered window.

Here is some very simple JS evaluation in action:

Skewering CSS uses the same shortcuts as JavaScript:

• C-x C-e – Load the current declaration into the window.
• C-M-x – Load the entire rule surrounding the point.
• C-c C-k – Load the current buffer as a stylesheet.

Styles are updated in the browser without reloading the page, making it very quick to test appearance changes.

In action:

HTML only uses a single shortcut:

• C-M-x – Load the HTML tag directly surrounding the point.

I tried this a couple of times but couldn't get it working on a live page.

Normally I would use C-x C-f (find-file) to open other files in a project. Projectile provides C-c p f (projectile-find-file), which is a very fast alternative.

Ignored files are automatically filtered from the list and it integrates nicely with Helm.

C-c p d works in a similar way for directories and opens them in dired. C-c p b can be used to switch between project buffers.

For most projects I'll have a terminal window open to run tests and compile code. Both of these things can be done using Projectile commands:

• C-c p P – Runs a test command for the current project.
• C-c p c – Runs a compilation command for the current project.

Each command will try to figure out the best function for the current project type. There are currently 30 different project types built-in, covering Rails, Symfony, Django and a bunch of other common platforms.

Project types are assigned by searching for specific files in the project root. For example, finding a Makefile file in the root will set the default compile command to make and the default test command to make test.

Projects can set their compile and test commands using Emacs .dir-locals.el.

• projectile-project-compilation-cmd sets the compilation command
• projectile-project-test-cmd sets the test command
• projectile-project-run-cmd sets the run command
• projectile-project-compilation-dir sets the directory to run compilation commands in.

These will override whatever type Projectile has assigned.

Example: .dir-locals.el for a Common Lisp project

((nil . ((projectile-project-test-cmd . "sbcl --script test.lisp"))))

The .dir-locals.el overrides make it possible to customize projects no matter what language or setup they're using.

Projectile's C-c p t command works most of the time, but a couple of my projects needed to be tweaked slightly to work properly due to the way test files are named and found.

To find the appropriate test file, Projectile strips the current filename of its path and extension, and then checks for a specific prefix or suffix.

For example:

"project/src/module/my_file.rb" will be stripped down to just "my_file". Ruby projects use "_test" as the suffix, meaning Projectile will attempt to open "my_file_test.rb" wherever it is located.

Some of my projects use the same name for source and test files, but stores them in different directories. It may be possible to extend this behaviour, but I'm still looking into that.

projectile-rails can be used to switch between models and views within rails projects.

For none-Rails projects, there are a couple of options, although neither are perfect:

• C-c p a – Switches between files with the same name but a different extension.
• C-c p g – Jumps to the file at the current point. This worked well for projects that explicitly named view templates.

Both of these options are supported and very quick:

• C-c p s g – Runs grep on the entire project
• C-c p o – Runs occur on all open project buffers

C-c p v opens version control for the current project. It automatically works out the best option based on what version control the project is under. For example, projects under git will open magit if installed.

There's no shortcut for renaming files, but being able to quickly open dired for project directories makes the whole process much easier.

C-c p ! runs a shell command in the project root. There's no shortcut to open a terminal .

It took a while to settle on a look and feel I liked. The design is still not completely finished, but it's a start. The build process was also simplified, which considerably decreased the build time.

Failed. Kind of.

I did spend some time working on game-related code. The majority was entity system related, but there was some game scripting in there as well. I've been working on both of those for a long time and I'd like to write more about them (as seen in #3).

I'll say this one is a success. I didn't write as much as I wanted, but I setup a new site to hold some of the more code-oriented things I write.

As well as my written goals, I worked on a couple of other things:

• Set up sodaware.sdf.org – This is a tiny site for me to fill with code notes and more in-depth software development articles.
• Worked on dogecoind-api – A Common Lisp library for interacting with Dogecoin.
• Worked on cl-dogechain-api – Another common lisp library - this one for working with the dogechain.info api.

I also did some experimenting with Common Lisp web frameworks and ORM libraries. I built a couple of tiny site prototypes, but I'd like to polish them up into something releasable.

There's a couple of libraries I'm working on that I want to finish and release. If possible, I'd also like to release a web project that uses CL.

#1GAM hasn't been as motivating as last year, but I'd still like to get at least one or two games built by the end of the year. There are plenty of game jams to enter, and short bursts of activity seem to work better for me.

This is working well so far. I have plenty of ideas, I just need to make the time to actually write them out.

Not very exciting, but I finally got around to rebuilding my game site at sodaware.net. The site is all static, using a mix of middleman and Jekyll, and also runs under SSL.

It took a while to get all the various parts working together, but I'm definitely happy with how the site looks and works now. There's still some work to be done (mostly polishing and removing dead content) but it's a good first step that I should have taken years ago.

My second success was releasing my first game in over two years. And boy, was it terrible! You can read more about it here: "February's #1GAM Entry - Trip into the Future". It wasn't particularly complex to build, and it isn't much fun to play, but it was a good step to getting back into the groove.

I'm still in the habit of leaving things to the last minute, but it's getting there.

The last few months have been a complete bust. But there's no point dwelling on the past. On to July!

This is another one of those "nice but not urgent" tasks that I've had in the works for years. Rebuilding the site to Jekyll was probably the hardest part, so the redesign should go smoother than the Sodaware one.

I have plenty of ideas, it's just a matter of finding the most realistic ones to develop. I have a tendency to over-complicate them which doesn't help when there's only a few weeks to create them.

A permanent goal that I frequently miss.