This investigation started off as a result of my frustration with the seemingly haphazard nature of looking for work using multiple avenues (websites, recruiters, leads from friends, etc) and keeping track of calls, e-mails and documents submitted (resumes, code samples, cover letters, etc), and the lack of options available to deal with this dilemma.

When I say lack of options, it doesn't mean there are no options. I've signed up for a jibberjobber account, and by and large it looks like a good site. But it means I have to figure out and learn something new, which won't have much use to me beyond the immediate need of finding a job. Something like trello or a self hosted kanboard could work, but they don't display 'at a glance' information I'd like to see.

Then I started writing my series of articles on self-hosting applications on a Raspberry Pi, and got re-acquainted with RedMine. Even though I'm a Jira fan, the inability of that to run on a Pi may have been fortuitous. With a bit of tweaking, it turns out that RedMine is actually a really good way of keeping track of job application statii. Beyond that, it has mobile clients available, and with a VPN (or hosted on a VPS), I have easy secure access to all my information, anywhere. Oh, and of course it's free and open source :)

Note the following:

• It is still a work in progress. If I find better ways of doing anything (or someone suggets something cool), I'll add it to the article.
• Though I've used RedMine, the approach below should work with almost any configurable issue tracker out there. The point is that it is not hard to formalize the job hunting process using available tools.

So, without trying to convince anyone of the merits first, I'll show you what I've done, and you can decide for yourself if it's worthwhile.

1. Getting ready

First, you'll need a copy of RedMine running. I'll be writing an article on that in the near future, but for the moment, you can use their website as a reference. You'll need to do the following:

• If you plan on having it available anywhere, you'll need a computer with some ports open to the interwebz, or a VPS.
• Install a copy of redmine - in short, it will run on pretty much any platform, and you will additionally need Ruby and a database server.
• If you want to be able to access your installation remotely, either an open port on your router (or VPS) or a VPN will be necessary. For security reasons, I'd suggest using a VPN (such as OpenVPN, which is included with most Linux installations).
• For android phones and tablets, there is a very nice client called MyMine (there are others - I just happen to like MyMine)

If you just want to try this approach without investing the time in setting up RedMine, you can apply for a demo account on RedMine's site. Note that it my be upgraded or reset at any time, so only do this to experiment - don't use live data.

Depending on my available time, I might look at putting together a Docker container with a configured RedMine at some point - watch this space.

2. Configure RedMine

This step assumes a clean install of RedMine, but nothing here should clash with any other configuration changes already made on a live system.

2.1 Create a new project

Each job application will be an 'issue' under this new project. Mine is called Job Hunting.

Enable the following Modules:

• Issue tracking
• Time tracking
• Documents
• Files
• Calender

Enable the following Tracker:

• Feature

Save the project.

2.2 Add issue categories

These will be used to track the current status of the job application. I use the normal 'Issue Status' to indicate the overall status of an application (New, In Progress, Closed).

My categories are:

• Investigate
• Contacted
• Resume submitted
• Initial follow-up
• Interview
• Post interview follow-up
• Accepted
• Postponed
• Rejected

2.3 Enable a default activity

Under Project Settings > Activities (time tracking), disable all but one of the items.

2.4 Add a custom field

By and large, I've managed to tweak the available settings in RedMine, but one additional field has so far been necessary - the recruiter or other source from where the opportunity came.

Under Administration > Custom Fields, add a new custom Issue field. Make the following changes to the configuration:

• Under name, enter 'Source'
• Tick 'Required'
• Tick 'Feature' under trackers
• Tick the Job Hunting project under available projects

2.5 Set up a custom query for your issues

The meaning of these fields will become apparent in the workflow section below.

Open the list of issues for the project (even if empty), and drop down the Options section.

Add the following fields to the box on the right:

• Priority
• Subject
• Source
• Updated
• Category

Select 'Group items by category'

Click 'Save' and give your query a name.

3. Workflow

Now for the fun part - actually using the setup you've just created!

3.1 Adding a new Job

Go to the Job Hunting project page, and click on 'New Issue'. Now complete the following fields:

• The Tracker 'Feature' should be selected by default
• Under Subject, fill in the company name, and position that the application is for (Developer, Senior Engineer, etc). Keep it short.
• Under Description, add any relevant links for the job, such as the job site listing, contact details, etc.
• Keep Status as 'New'
• Change the Priority based on application importance. If it's something you think you're very suited to, change it to 'High' so you can keep an eye on it.
• Under the Category list, select 'Investigate'.
• Under your custom Source field, add the name of the recruiter or recruiting company, job site, or friend where you got the job information from.
• If you have a document copy of the job description (other than the website), upload it under Files

Select Create.

3.2 Updating the job application status

Every time you do something related to your application, that information should be captured. In RedMine, we do this under the Log Time function.

Select the Job Application (Issue), and click Log Time. Complete the following (and leave the rest as default):

• Hours - how much time was spent on the activity (useful to get an idea of how much effort you're putting into specific job applications)
• Description - brief description of the phonecall, e-mail, interview, or anything else that might be relevant

Click Submit.

In addition, if the application has now changed categories, edit the issue, and update according to the following rationale:

• Investigate - A jobsite posting or lead could be interesting - investigate further
• Contacted - An email, phonecall, or online application has been sent
• Resume submitted - I've formally submitted a resume, cover letter, and any other documents that may be required
• Initial follow-up - I've spoken to the prospective employer about my application, and I know that it is in the system
• Interview - I've been invited to an interview or follow-up interview
• Post interview follow-up - I've been in contact after an interview, and know where I am in the system
• Accepted - You have been offered the job
• Postponed - The employer has temporarily put their recruiting drive on hold
• Rejected - Your application has been turned down (be sure to mention a reason)

Also change the Issue Status to 'In Progress'.

If any documents have been submitted (cover letters, references, etc), attach copies to the issue. This is useful if you need to quickly find what exactly you've sent to the prospective employer.

3.3 Viewing your applications

There are two ways to see 'at a glance' what's been happening in your job hunting process:

The custom query that you created will order (by category, ie application status) your applications in the Issues view. Here you can see:

• All the jobs you've applied for, and your progress in each one
• When the last time was that you changed anything on an application (useful to see when you might need to ping someone)
• Who the recruiter is that you need to contact about a specific job

Clicking on a specific application, you can see the information you initially entered or updated, as well as the following:

• A history of changes (job status, documents uploaded, additional information added)
• By clicking on Spent time, you will see a history of contacts made with regards to the application (specifically, dates and times, and the comments you added every time you logged time on the application)

3.4 I've found a job!

Great! Log time to the application, change its status, and use your application list (as a courtesy) to let other prospective employers know that you've been snared.

Hang on to the project though, since it will be useful next time you start job hunting, to see who you've applied to, where in the system you were with them, why you may have been rejected, etc.

4. What next?

There are obviously still things that can be improved in the workflow, but these are partially limited to the functionality provided by the issue tracker.

Some applications may require very specific actions. By and large, the above setup has proven to be reasonably robust for me, but it is pretty easy to modify without impacting existing information.

Feel free to leave any comments or suggestions. I'd also be really happy to hear if this helps someone to take the drudgery out of job hunting.

Roelof

1. It's not hard

Just what the title says - it's really not hard :-)

The software available to run your servers with (both OS and application) have matured massively over the last decade, and there are hundreds if not thousands of people on the interwebs willing to offer support in some form or another. For that matter, it's extremely unlikely that you will run into issues that have not been addressed by others, and answers are usually a well-worded google away.

Online resources abound in the form of forums, knowledgebases, FAQs, e-books (free and paid), chat rooms, etc. They also tend to cater for people of various levels of experience. One of my favourite sayings applies here - the only stupid question, is the one you didn't ask. Even if the answers aren't always worded nicely, you will learn from it.

---

2. Benefits

Apart from learning new things, there are a number of benefits to running your own servers:

Your data is your own

By storing your data on a server that you control, there are no risks of running foul of international data search-and-seizure laws. Your data will also not be collateral damage in the case of massive security breaches, password leaks, lax security measures, or targeted hacking attempts (unless you're the one being hacked, of course). Though this security-through-obscurity approach is often frowned upon, you generally won't be targeted if nobody knows that your server exists.

You have control over who has access

Whether it is work documents or photos of your cat, you can control who sees them and who can modify them. There are also no issues with changing privacy statements allowing people access, with no prior warning. You can give and revoke access easily and quickly, to anyone.

Managing your data life cycle becomes easier

By having all your data in one location, hosted with open source software, it becomes easier to backup, easier to synchronise across multiple devices, easier to migrate, should you choose to do so, and will not be subject to public cloud services shutting down.

It can actually save you money

Depending on the level of service you use from public cloud providers (free vs premium), running open source software on your own power efficient hardware could cost you less per year than paying for numerous services.

Of course, these benefits can be negated in an instant if you don't take heed of some of the other basics here (#3 and #4 specifically).

---

3. Security

A responsibility that will now fall on your shoulders, is security of your infrastructure and data. If done properly, it's not all that hard though. Generally, by using well-maintained open source software, security vulnerabilities will be patched if you keep the software up to date. Other things, like setting up users and network access, need only be done once if done properly.

Network access

This includes items like setting up firewalls, closing ports, forwarding ports, etc. The approach in this series of articles follows one of minimal external access via VPN and SSH to reduce the possible area of attack.

Authentication

User and computer authentication can be as easy or as hard as you decide to make it. This will generally be a function of how important or sensitive your data is, and how many people will have access to your server. Options include:

• Username and password
• Username and private keys
• Two factor authentication
• HTTPS with client side authentication

Physical access

A common maxim is that all bets are off if an attacker gains physical access to a computer.

This is no less true when running your own servers. Security measures taken will likely reflect the importance of your data and the likelihood that someone will want access to it. For most people though, the biggest concern will be hardware stolen during normal burglaries. In this case, it's unlikely that they will be after your data, and you can restore from the backups you've made.

---

4. Backup, Backup, Backup!

The importance of backups can not be overstated here.

In a sense, by not using public cloud servers, you are now putting all your eggs in one basket. This is not a bad thing, as long as you are prepared. Regular incremental and/or full backups (stored locally, but preferably off-site) are not hard to do, but absolutely essential when you are actively storing all your information in one location.

A useful side-benefit is acquiring an awareness of how fickle storage systems can be, and becoming more proactive about backing up ALL your data in other locations.

It should also be pointed out that this process is remarkably easy to automate.

Don't be one of the people who start worrying about backups 10 seconds after you realise your drive failed (data recovery is VERY expensive, and not fool-proof).

Backup vs Redundancy

It is important to note that backup and redundancy are not the same things. While prudent, storing your data on a redundant drive setup (local RAID, NAS, etc), will only protect against drive failure.

If something catastrophic happens at the location of the redundant drives (power surge, theft, fire, etc), ALL your data will still be gone!

---

5. Infrastructure

Running your own server or servers requires some thought about infrastructure, but could be as trivial as where to place the hardware. The questions below are not exhaustive, but are meant to kickstart thinking about infrastructure.

Network

• Do you have the required up- and downstream internet speeds to access your data easily?
• Will you be attaching your server with wired ethernet, or wireless?
• Do you need more than one NAT firewall (router) between the internet and your important data?

Hardware

• This series of articles will focus on low-powered hardware, but the type of services you plan to run will likely influence this.
• Where will you place the server/s?
• Do you have sufficient cooling, if it is a high powered server (or if it's in an enclosed area)?
• How much storage are you likely to need?

Power

• Do you need additional power for extended power outages (UPS vs Generator)?
• What UPS size do you require?
• Have you installed proper lightning protection?
• What will the estimated power use be (and the impact on your power bill)?

Redundancy

• Is it acceptable for a server to be down till you can physically attend to it, or do you need failover hardware?
• Do you have storage redundancy in case of drive failure?

---

6. Physical (on-premises) servers vs VPS (Virtual Private System)

This is more of a sidenote, but I thought I'd mention it anyway.

While it's entirely possible to run your own server on services like Digital Ocean or CloudAtCost, it does negate some of the benefits mentioned #2 and #3 (but also takes care of some other issues like #5 ).

I would personally recommend only using these services if:

• You're toying with the idea of running your own cloud server and want to experiment first
• The data that you'll be storing is not sensitive in any way
• You do not have reliable internet and power at home

---

7. Learn and have fun

With reference to #1 above, whether you're a seasoned system admin, or just getting started, setting something up that you can actually use, is a useful and fun learning experience.

Generally, you have to stuff up pretty badly to lose important work (see #4 ), and rollbacks are part of the learning experience.

If you're in the position of doing something that somebody else hasn't done yet, and you get it going, the feel-good factor is even higher, and you might even be the one to help someone else with the same issue on a forum somewhere.

Roelof

This project started as a scratch for a number of small itches:

Running my own servers

Like any self respecting geek, I like running my own servers to try things out on, and even occasionally use them for doing useful things.

I don't trust the cloud (for important things)

There, I've said it. Useful and revolutionary as it is, cloud based servers still have drawbacks that concern me, specifically the fact that I don't really own my data after I've uploaded it into the ether. This topic is worth a post on its own, so I digress for now.

Electricity is expensive

Gone are the days where thinking about your electrical bill is a distant afterthought when running computer hardware. In Queensland, 'normal' residential electricity is now billed at around A$0.27/kWh. Running a full size headless box (~100W idling), comfortably costs in excess of A$250/year. Apart from being expensive, it is also a waste of resources, and bad for the environment.

---

Having bought an original Raspberry Pi B (with 256MB RAM) when they first came out, I thought I'd give it a try to see how much I can run on it. It turns out that the memory ceiling is just a tad too low, so I went and spent a whopping $50 to buy myself a new B+. Not that the first Pi is going unused, but more on that later.

Using the two Pis and a number of self-hosted packages, I'm in the process of recreating a personal cloud setup that mirrors a number of services I've used for non-critical data, while also addressing the issues mentioned earlier:

• I get to run my own little (cheap) server with useful stuff on it that I can access from anywhere;
• All my data is stored at home (making it easy to backup, and fast to use locally), but available to me via secure channels on the go, just like normal cloud services;
• At 5W, the Pi sips electricity. Even with an external hard drive attached, it only touches 10W when running balls to the wall. A side benefit of this is that even a small UPS will keep my server stack going for more than an hour (less of an issue in Queensland, but very useful in places like South Africa right now - thanks Eskom).

How much can I run on a Raspberry Pi, considering it sports somewhat 'limited' hardware compared to modern servers, and still have decent performance? It turns out, quite a lot! My current (in progress) setup has the following running on my B+ (with average load and memory usage under 50%):

• GitBlit (running under jetty)
• Apache with modPHP, running:
  • Redmine
  • Linux Dash
  • A local ubuntu & debian repository
  • Dokuwiki
• NTP server (based on a Freetronics RTC)
• apt-mirror
• OpenVPN
• rtorrent

On my to-do list are:

• Owncloud
• A mail server
• Wallabag (a pocket clone)
• A download manager
• Datacrow (a library/catalogue application)
• Upsource (repository browsing and code review tool)

---

I will be posting a series of entries on this topic, covering a number of items like security (login credentials, running a VPN, etc), accessibility issues (commandline and web based services) and self hosted services (in areas like general productivity and software development). Initially, my focus will be on security and productivity, more than sharing or hosting things for other people to see. However, the latter is certainly possible without compromising the former too much.

Hopefully, it will inspire others to do the same (once they see that it's actually not hard), and I hope to add some value by automating some processes, or making services easier to deploy.

Watch this space!

Roelof