Tag: GitHub

Job Hunting Checklist

Jeroen

Having recently switched jobs, now is probably the best possible time for me to write about the applicant’s side of vacancies and job searches in IT. Specifically, I want to give my take on maximizing the chance you’ll land a job at a place you’d want to work at. Put differently, below is (mostly) my own plan for finding a new job.

But wait: that’s not specific enough for a blog post yet! There’s a lot to job hunting. So let me narrow it down to the asynchronous ways to communicate with prospective employers.

What I mean here by “asynchronous“? Well, that includes just about everything that’s not real-time (face-to-face or phone conversations, chat, etc.). I will run down these “channels” one by one, including specific tips for each.

By the way, I hear you thinking: “But that sounds like just a big check list!?”. It is. But hey: check lists are great! Use this one to your advantage. Let’s get started with the basics.

General tips

Several things are important for all of the async channels. Remember:

  • Choose a great avatar you’ll be happy with for a long time to come, and stick with it. Everywhere! This will take a few years to settle in, but after a while it’ll help people recognize you across the board.
  • Be smart about your e-mail addresses. Preferably, you’d get your own domain, use addresses like some-org@yourname.com and github@yourname.com. Alternatively, use the + sign lifehack to differentiate. This will help you separate incoming mail reliably, lets you know who’s leaked or sold your e-mail, and gives you a minor edge with tech orgs because they’ll notice you’ve given things some thought.
  • Do or do not, there is no try. To put it in my own words: either do something right, or don’t do it at all. For example: it’s better to have no LinkedIn profile than an out-of-date one.
  • Try to do as many of the list below as possible, but consider this tip strictly lower priority than the previous tip!
  • Use language correctly, or at least as correct as possible. It’s easy to use a spell checker, proofread, do some proofreading, and do some more proofreading. Tip: read your writing (semi) aloud to yourself to find bugs in your writings.

Okay, so enough with the generic mumbo jumbo. Off to specifics!

Your CV

A lot has already been written about this, so I won’t repeat the basics. But I will make a few important additional points:

  • Decide: short or long. Both are fine. If you go short: try to fit everything on one single page. This is really hard (I could never do it!), but if you can manage it’ll demand respect and it’ll be useful to the reader. If you go long: use “scannable” text and styles (tables, bullet lists, emphasis, and so forth).
  • Use a (non-default) theme. The theme (and sticking strictly to it) will help prevent your CV from becoming ugly. Only try to make a “beautiful” CV if you know how to design or have help in this department.
  • Read “The Non-Designer’s Design Book“. It’s a “Must-Have” if you insist on tweaking styles (like me), and when you’re also (like me) not a great designer. It’ll at the least help you prevent your CV from becoming ugly.
  • Use serif fonts. Sans-serif might look nicer on (non-retina) screens, but most of the time folks will read a print of your CV. On paper, a serif font is easier to read.

Open Source platforms (Github, Gitlab, etc)

This one’s not for everyone. Whatever you do or don’t do: be conscious about your choices. That doesn’t mean everything has to be perfect, but do mind the things that are easy to get right. Think about cleaning up utter garbage repos, using correct language when commenting on issues, etc.

If you do decide to work on open source, note that you don’t necissarily need to become a maintainer of a high esteemed project to be noticable. Here are some easier ways to get started:

  • Pet projects are something to put online. Place a big disclaimer that the code should be viewed as such, and you’re fine putting out non-production-worthy code.
  • Create a demo project that shows off how you prefer to code. It’s fine to “reinvent the wheel” or even create yet another “To Do App”, as long as you focus on the code being in “your” style. Place a big disclaimer that the code should be viewed as such, and you’re fine.
  • Create Issues for other projects. Creating an issue with a good repro is usually well-received, and displays qualities very important in day-to-day tech work.
  • Find up-for-grabs issues in a project you’d like to contribute to. Or even open your own (most projects will welcome improvements to documentation, for example).

On a side note, it can also be good to spend some time looking at the source code of open “famous” source projects in your tech stack. It hones your code-reading skills, and demystifies the black boxes they tend to be. Although this isn’t directly visible to prospective employers, it does have intrinsic value and might be a gateway to your own contributions some day.

Community Forums and Q&A (Stack Overflow, etc)

On the one hand I see this different from the previous point (Open Source), on the other hand it kind of isn’t. Specifically Stack Overflow (of which I’m somewhat a fan, as they distribute all content freely, for one because the data is licensed by users at least under CC-By-SA.

Asking questions is probably the easiest way to get started. Note that exemplary questions are a great way to show off your skill: being able to grasp and neatly summarize a reproducible problem is perhaps the number one skill a developer can have. I’ve asked multiple questions I’d proudly show off as part of my resumé.

Answering questions is a lot harder. This is another whole topic on itself so let me just sprinkle some basic advice. First, the “gamefication” can be fun but should not be your primary motivation. Instead, answer to learn about topics. Choose a low(ish) traffic tag to answer questions in, or you’ll get frustrated by the fastest gun in the west: other people will answer extremely fast so you don’t seem to have a chance. And finally: keep at it.

My first few questions and answers on Stack Overflow were pretty bad, but practice makes perfect! For every ten answers with even one upvote there’s at least one that turns out to help a lot of other folks. Seeing a small “+1” trickle in on an old question is a great, warm feeling.

A personal website

Get a personal domain, preferably something with your name in it. Make it a single page with at least:

  • A very basic bio: one or two lines of text about who you are.
  • A generic e-mail address (one that doesn’t matter if it gets a bit of spam).
  • Links to any social media accounts, e.g. Twitter, LinkedIn, but also Meetup, Goodreads, or other media that are professionally relevant.
  • Links to open source profiles, e.g. your GitHub profile or Stack Overflow flair.

Then, optionally, you could do any of these:

  • Link to your blog (see next section).
  • List of your projects, e.g. pet projects, portfolio stuff, your master’s thesis, etc.
  • Link to interesting other sites, e.g. tech blogs you enjoy.
  • A short occupation history if you’re inclined to make that public.
  • Some schema.org info and meta tags for SEO and generally showing off mad skills with details.
  • Ninja-counter-recruitment in your source code, just as organizations do.

A personal blog

Also not for everyone, but it certainly does help showing off enthusiasm, writing skills, and really whatever you want to show off. Blogging about tech is great, but mixing with non-technical posts works even better.

And in addition to exposure, there’s a far more compelling reason to blog: writing helps you organize your thoughts. Having to clearly express your thoughts or opinion about something should also make you think really hard about that thing.

Gaining a bigger audience is a challenge on its own, not usally directly related to the writing itself. So think long and hard before you decide to go down that road, because you’ll have to double down on community-building to get somewhere. But then again: I feel you can get a lot out of a blog without a big audience, too, by just writing to organize your thoughts.

Social Media

Warning: only do this if you enjoy it! The days of “needing” to be on social media to fit in are gone with Gangnam Style and the rest of 2016. Having said that, social media can be helpful in building your online profile.

First up: be consistent. Be consistent with your tag line, title, etc. Be conscious about what you make public and what you keep private. Don’t be afraid to create only a simple account that just links through to another platform; for example, you could create a LinkedIn profile that just tells folks to check your own website.

For the rest this comes down to personal preference. For me, Twitter and a wee bit of LinkedIn are primary professionally used social media. Google+ I find useless for most things, and Facebook is purely a thing for friends and family for me.

As a footnote it’s also worth noting that there are outliers. Goodreads is something I only use because I find the platform interesting, and I keep my professional bookshelf there. Also, Meetup.com has been popular the last two years, so I guess that also counts as a medium to be conscious about.

In closing

Bear with me while I digress a bit. Suppose you want to set up a perfect romantic date with someone. To maximize chances of success, you prepare all the things that can be reasonably prepared. You make sure there’s food, drinks, music, but also toilet paper, running water, etc.

Now let’s zoom in on the food. If you’re a chef or if you like cooking you might go out of your way a bit to cook something fancy, though you probably shouldn’t go too risky (unless that’s part of your charm…). If you hate cooking dinner you might order in something nice, and focus more on other things. In other words:

  • Do or don’t do! There is no “try”.
  • Min-Max All The Things™ that you do.

Back to the point. Maximizing your chances for a perfect job works the same as setting up that perfect date night. Be conscious about what you focus on. Be smart about what you do or don’t do. And whatever you decide you will do: do it right!

Footnote: his was also cross-posted to the Infi company blog.

Git intro for TFVC users

Jeroen

So, you’re using Team Foundation Version Control (TFVC). You know about Team Projects and Collections, have a “stable” and “dev” branch for most projects, know how to do basic merges, and know how to shelve and unshelve changes. But you only have superficial knowledge of Git.

Well, then you’ve come to the right place: my Git intro for TFVC users.

Disclaimers

Here’s a heads-up about this particular post:

  • It is not in-depth;
  • It will oversimplify things to the point where not every statement is technically true;
  • It does not teach you actual Git skills or commands;
  • It is somewhat subjective.

Oh, and in my humble opinion: Git has a crazy learning curve. So buckle up!

And, as a final disclaimer: I’m writing this because I want to be able to explain the basics of Git, and certainly not because I’m an expert. In fact, I know more about Mercurial than about Git, I have worked mostly with TFVC in the past year, and would have to look up nearly every Git command when using the command line (I prefer GUI tools most of the time). Just so you know.

Disclaimers done, let’s get started!

On “TFS” vs “TFVC”

First, let’s get the TF* terminology right. These terms are different but related things:

  • “TFVC” stands for Team Foundation Version Control, and is the actual system for keeping history of your codebase;
  • “TFS” stands for Team Foundation Server and is the “environment” (if you will) in which source control features come together.

Many people, myself included, often use the acronym “TFS” when we actually mean “TFS with TFVC”. This is probably because TFS is very often used with TFVC as the version control system; but note that you can also use Git with TFS.

This blog post focuses on TFVC (which almost always implies you’re using TFS too).

Why Learn about git?

The personal reasons for learning Git are quite simple: it’s the de facto standard for version control. Knowing about Git is:

  • crucial for your career (your new employer is likely to use Git);
  • crucial for talking to new hires (who will very likely know Git);
  • crucial for efficiently navigating open source.

The intrinsic reasons for learning Git all come down to the fact that it is insanely powerful (which also accounts for the steep learning curve). After having worked with TFVC in a 12 person team for over a year, I’d like to highlight the following main- and most direct advantages over TFVC:

  • Cheap branching;
  • Small repository size;
  • Local commits;
  • Better options for “shelving”;
  • Speed;
  • Better “offline” support.

Beyond these advantages, which you’ll get if you’re using a “central” Git repository, there are even more goodies if you tap into the distributed nature of Git, as well as the more powerful commands (e.g. to rewrite history).

Basic differences

Git is a lot like TFVC, in that it is also a Version Control System (VCS). It is also quite different. Here’s how they compare when managing the code base and doing changes:

TFVC Git
There is a central, server-hosted Team Project and you’ll have one or more local workspaces containing a copy of all the code. For now, let’s assume that there is a central repository hosted somewhere on a server. You’ll have one or more local “clone” repositories containing a copy of all the code and also all of its history.
A check in is a command to send your pending local changes to the server where they will be committed to the version control history. You commit changes locally which creates a “change set” private to your “clone”. You can do this multiple times. You push one or more change sets at once to the central repository.
You can Get the Latest Version from the server which directly tries to merge with your current state. You fetch changes from the central repository and merge with your current state (or do both at once by doing a pull) possibly creating a new commit.

The fact that a TFVC “check in” is multiple separate commands in Git gives several advantages:

  • You can build history in small, individual steps (commits), which you can undo individually in several ways, and you can apply individual commits to other branches.
  • Your changes are “safe” in commits when you want to send your changes to the central repository and find out others have conflicting changes, by default they won’t get “lost” if merges go bad. With TFVC, you’re required to resolve conflicts as you try to check in, which can screw up “unsaved” changes.

Our next set of differences would be about branching, but before that it’s good to talk briefly about “shelving” changes.

Setting changes aside

With TFVC you can shelve changes you currently have to safeguard them, optionally reverting those changes in your local workspace. You don’t necessarily need to do this when switching work to another branch, because the branch is typically a sibling folder of the main branch. More on that later.

With Git, you can stash changes you currently have, reverting changes in your local clone. You have to do this before switching to another branch. In order to see how that works, let me move on to the next topic: branches.

Branches

A typical setup in TFVC starts like this (with a local workspace matching the Team Project 1-on-1 in this example):

Inside the project folder for the Team Project, there immediately is a sub folder called “main”. This is done so that it is easy to branch off the entire codebase for that project into this:

The folder “dev” is now a complete copy of “main”. This also means you could be working on two branches simultaneously, and you can check in files to both branches at ones if you so desire. You could even have “main” and “dev” at different points in your version control history.

Git is different.

With Git, the “main” folder as you’d have it in TFVC would be pointless. Instead, there is just:

You can “branch off” any state of “project-x” at any point in time. Your folder “project-x” will point at a certain state, de facto having the code for a specific branch.

If you would like to have both branches “ready for action” on your disk, you would typically have multiple “clones” of the repository. One would be at the most recent state of the “main” (typically called “master”) branch, and another might be at the most recent state of another branch.

As a summary, Git branches relative to TFVC branches:

  • Are light-weight and can be used to “switch context” for example to work on a feature;
  • Are a top-level thing, as opposed to the “path-based” branches in TFVC;
  • Allow for more precise merges and “cherry picking” of commits;

These differences allow for completely different workflows with Git. This is a topic for another post though, if you’re interested I’d recommend research things like “Git Flow”, “GitHub Flow”, and “GitLab Flow”.

Other differences

While there are many other differences, both small (e.g. specific commands) and big (e.g. the “distributed” nature of Git), this post will keep it at the above. Mentioned differences are in my opinion the most “direct” and eye-catching differences. If you want to learn about the other differences I recommend you first get started with some practical skills, e.g. by following a tutorial.

Conclusion

TFVC is a mature, decent version control system. But personally, having worked with both centralized and distributed version control, in TFVC I’m misssing:

  • Ability to do commits locally;
  • Cheap, more powerful branching;
  • Great “shelve” options;

Those three, in addition to its “distributed” nature enabling online platforms like GitHub to flourish, are likely the reasons Git is so popular nowadays. In my opinion those are great intrinsic reasons to learn Git when you’re currently using TFVC (even if you cannot switch on the short term), and if not for those reasons then because it’s crucial for your career.

So ready yourself for a bad-ass learning-curve climb, and start learning more about Git!

Resources & Further Reading

Here are some links to continue your journey:

Pet project status report

Jeroen

This post assumes you’ve read my previous post on this project. It’s going to be a very short status report.

In aforementioned post I’ve tried to break through my analysis paralysis by listing all the things I had to think about (it helped!). Let me re-iterate, update, and complete the list to once again gather my thoughts:

  1. ✔ Project and Namespace structure. KISS, so I went with just a single project (plus one for tests) for now.
  2. ✔ Folder structure. following the lead of popular C# projects, only needing some files in the root and a src folder for the projects.
  3. ✔ Initializing git. this was actually the biggest mental blockade. I just bursted through: screw TFS history, screw being “optimal”, and just move. I copy-pasted all code, cleaned everything carefully, and initialized the git repo with an already decently sized project.
  4. ✔ License. MIT.
  5. ✔ GitHub setup. Let’s start simple. Project created under our organization’s GitHub account. Pushing straight there for now, using my own personal profile. Will think about working with forks and pull requests later.
  6. NuGet packaging. Haven’t started this yet.
  7. Re-including the open sourced bits in my closed source solution. Have postponed optimizing this. The not-so-optimal solution for now is that the projects are gone from TFS, and there’s a “lib” folder instead with compiled DLLs from the open source project.
  8. ✔ Choosing a name. Chosen, but not ready to disclose yet, even though it’s very easy to sherlock this bit.
  9. .NET Core. We’ll cross that bridge when we get there.
  10. ✔ What am I forgetting? Looking at some of the “top” C# GitHub projects (Restsharp, NodaTime, dapper-dot-net, AutoMapper) was extremely helpful. Note to self: in-depth code reviews of those projects will be extremely educational.
  11. ✔ Minimum quality. I actually chose to make this project an exercise in being as “clean” as possible (within -though close to the edge of- reason). But one bullet at a time, so e.g. crafting a great readme is a sub-exercise left for later.
  12. Early feedback. Still on my list, but want to get to some kind of “alpha” stage before I send out review requests.
  13. Logo. Was a great excuse to get started with the recently released GitHub Projects feature.
  14. ✔ XML Documentation. Probably way over the top, but a nice personal exercise, so worth it after all.
  15. CI. Have not started with this yet, but know I have to at some point.
  16. GitHub Wiki. Probably way over the top, but would be a nice personal exercise to create one.
  17. Domain name. Not sure how that plays together with the license, the fact that the repo was initialized under my organization’s account, or any trademark stuff. Will have to figure that out some time soon.
  18. .NET Framework Versions. Related to the .NET Core bullet I guess, but slightly more important. I found that the popular repo’s I looked at for guidance have some kind of setup with duplicated projects several times over, not sure how that works. For now I’ll have to stick with a (unfortunately slightly older) version, 4.5.1, because that is the highest version I can use in the project that is dog-food-testing the project.

Okay, now I can stop that hurricane of thoughts, and get back to this pet project, and tick some more things off the list!

Extracting and Publishing closed bits as Open Source

Jeroen

There’s a project at work that’s got all the traits to serve as a great vehicle for dabbling some more with open source:

  • Small-but-not-too-small;
  • Self-contained;
  • Not too specific (e.g. to our domain);
  • Keeping the IP safe isn’t a concern since it’s just a small tool unrelated to the core business (i.e. we’ve got “the okay” to make it open source);
  • It might be of some use to someone else, and failing that it’s still fun to open source it;

While trying to start with the process of extraction and open sourcing, there seem to come up a million things to think about when going through this process. I want to gather my thoughts (by writing this post) and untangle that mental mess, so that I can get to a clear plan of attack. Perhaps this post will even be of use to someone else, somewhere.

Context

Currently, the bits I want to make open source are only slightly coupled to the bits I want to keep closed. That is: currently everything is in one solution, but the split in projects already clearly demarcates what would be open and what would remain closed. To put this in a tabular overview (where “Foo” is the closed bit, and “Bar” is the open bit):

Current Situation

Closed Source

/Foo.App
/Foo.App.Tests
/Foo.Core
/Foo.Core.Tests
/Foo.MyInstances
/Foo.ConsoleWrapper
/Foo.ServiceWrapper

 Target Situation

Open Source

/src/Bar.App ???
/src/Bar.App.Tests ???
/src/Bar.Core
/src/Bar.Core.Tests
/src/Bar.ConsoleWrapper
/src/Bar.ServiceWrapper

Closed Source

/packages/Bar ???
/Foo.MyInstances
/Foo.WindowsService ???
/Foo.Console

There are some question marks in that overview. Elaborating on them a bit:

  • I’m not sure if the distinction between “Core” and “App” should remain a dll/project splitup as opposed to possibly a namespace split.
  • I’m not sure how the Open Source solution will be included in the closed source app (via NuGet, or as external source or binaries, or…?).
  • I’m not sure if I can easily distribute a generic windows service wrapper, or if I need to create it in the closed source solution after all.

In addition to these source-related questions, there are other things to think about as well. So next up:

What things to think about beforehand?

Let’s summarize all the things I can currently come up with that might be important in this process, in no particular order, merely numbered to be able to reference them easily:

  1. Project, Namespace, and DLL structure: what’s wise, what’s neat, what’s useful?
  2. Folder structure: how will the repository be structured? What’s future proof here?
  3. Initializing git: currently, the project history is in our corporate TFS. So not even sure if/how to keep the history intact, or if that’s even feasible.
  4. License: okay, that’s not too difficult, but have to choose one nonetheless.
  5. GitHub setup. What’s a good setup? Should I make the organization main owner of the repo, with a personal fork from which I do pull requests?
  6. NuGet packaging: how does this even work? As an application developer I had never had the need to learn how any of this works.
  7. Re-including the open sourced bits in my closed source solution: via NuGet, as external source, or as external binaries?
  8. Choosing a name. One which is not already in use for some software, where a domain with “normal” extension is still avaible, where the name is not taken on GitHub yet, etc.
  9. .NET Core. From my rss feeds I gather that it can be a quite fuss to make open source projects .NET Core “proof”, but it would be yet another thing to tackle while starting this whole thing off. Perhaps something for later? Or is that a grave mistake?
  10. What am I forgetting? I’ve been looking at some of the “top” C# GitHub projects (Restsharp, NodaTime, dapper-dot-net, AutoMapper) and their git history to see how they have evolved, to find out if I’m forgetting anything.
  11. Decent starting point, code-wise: I might be setting unreasonably (and unnecessarily) high standards for the initial commit, but still something to consider. What is the minimum quality I’m requiring before opening the source?
  12. Early feedback: it might be useful to get friends and colleagues to review the setup and get the first version(s) of the repository just right.
  13. Logo: yeah, this project needs the best. logo. ever!

In addition, there’s a practical point: once I split off bits to an open source project, I’ll effectively have two (source-control-wise unrelated) forks of the same code-base, until I’m ready to make my closed source solution depend on the open source bits again.

In Conclusion

After writing the above: wew! No wonder I was not getting anywhere: my mind was just wandering in circles through all of the above points. And I guess “Perfect is the enemy of Good”, or some such. Time to tick off some of the above items.

Aggregated online interactions

Jeroen

This blog hasn’t seen much action lately, but that’s a misrepresentation of my online interactions. Most of my interaction in the past few months has been on Stack Overflow Q&A, and some on Stack Overflow “Documentation” as well as a small amount on GitHub. I wanted to aggregate some of those interactions on my blog, as well as perhaps cross-post bits and pieces here, mainly for my own reference.

Let’s start with the first: aggregating the bits and pieces that I want to have easy links to.

Stack Overflow Documentation

  • “Showcasing all common Angular constructs“. I’m linking to the most up to date version. I wrote V1 of that article, which was subsequently improved by various other folks. It’s the tutorial (and equally important: the style of tutorial) I wish I’d had when I started learning Angular.
  • KnockoutJS “Equivalents of AngularJS bindings“. Linked page summarizes the state SO Documentation is currently in, at least for low-traffic tags: little and poor collaboration, and some frustration because some decent examples I wrote just don’t get reviewed (neither approved nor rejected). Thinking I might turn my content there into a (series of) blog post(s) here. Not sure yet.

Stack Exchange Q&A

At around 20 questions and 200 answers in 2016 so far I’d say I’m “moderately active”. Here’s a few that stood out when I browsed through my recent history:

I also gave SoftwareRecs.SE another shot, posting some questions, but they fit right into my question history: lots of unanswered tumbleweeds. And not for lack of trying, as I spend a lot of effort on making my questions there as good as they can be. The main reason I do that (and the reason I keep coming back to softwarerecs.se, in spite of the tumbleweed-factor) is that thinking carefully about your wishes and requirements at the least will help you find something yourself, if no-one else recommends anything.

And even though I haven’t interacted with Cooking.SE much lately, every stray upvote now and then to my “Cooking fish in a dishwasher” answer makes me smile.

GitHub

I don’t interact as much here yet as I’d like. I specifically wish I remembered more often than a measly four times to create gists, because the ones I did create are ones I tend to go back to. In addition to gists, I’ve gotten to creating only very few issues and pull requests, something I want to work on.

One shoutout by the way to the DefinitelyTyped repository, because that community has to deal with a really scattered committer base, and seem to do so pretty well. My pull request (though small) was reviewed and merged quite quickly.

In Closing…

What to do next? The tags I followed on Stack Overflow for answering seem to have dried up a bit. Perhaps some more interaction on GitHub, as well as re-editing some of the above links into blog posts? Then again, a few weeks of vacation to Hawaii are coming up as well, so it might be a while again before posting…

Finishing Things – Intermezzo part 2 of 2

Jeroen

So, like I wrote, Google is “bidding farewell to Google Code“. So my recently “wrapped” up projects needed some post-wrapping-wrap-up (you still with me?!). I’m using this as a good excuse to partially move from Mercurial to Git, because I suspect Google Code’s export to GitHub is probably the migration path they’ve put most effort in.

So, here’s my first (active) day at GitHub:

GitHub Contributions

I’m a little afraid that -given GitHub’s popularity- many will see this and consider it to be my current status on code hosting services (disregarding commits to those repo’s being done over a larger time span, and disregarding activity on CodePlex). However -given GitHub’s popularity- I guess my GitHub activity will increase anyways over the coming years.

As a related side note: moving projects from Google Code to GitHub was extremely easy. The web-based tool required nothing besides a link to my Google Code project, and me authorizing Google Code in GitHub through OAuth. The only downsides I personally found during this automated conversion:

  1. My old commits in the migrated GitHub repo’s don’t get attributed to my GitHub account, because the user details were different. Also, apparently TortoiseHg “helped” me commit unwittingly as “jeroenheijmans <jeroenheijmans@localhost>”. I guess if I’d payed attention I (sh/w)ould’ve at least used a valid e-mail address. (Yes, given that probably no one has cloned my repo’s (yet) I could probably rewrite history to change this, but it’s not that big a deal I guess…)
  2. My repository includes some Mercurial-specific files, i.e. a .hgignore file. I might’ve stripped that if I had done the Hg-Git conversion manually.
  3. The project home page from Google Code was not automatically added as a README.md file in the GitHub repo. I think that would’ve been nice. Then again, this omission gave me a chance to check out Git(Hub).

And so my move to Git(Hub) begins. I’ve already enjoyed reading through other people’s thoughts on (Git) commit messages, had my first dealings with Atlassian SourceTree, as well as a combination of the two. You’d almost wonder how I got the actual migration done at all.

I feel excited about getting to know more about SourceTree, Git, and GitHub. However, I’m also still very determined to finish Bieb, which will remain on CodePlex. We’ll see how that plays out in the coming weeks / months. Stay tuned.

Finishing Things – Intermezzo part 1 of 2

Jeroen

In the beginning of 2015 I declared I was wrapping up my open projects. I’ve since quickly wrapped up BattleTop, TimeLine, and DotaGrid. After that I’ve started to work on my somewhat bigger project: Bieb. I haven’t had as much time to put into that project as I wanted, but there has been a thin stream of commits.

However, all this has been brutally interjected by Google: they’re “bidding farewell to Google Code“.

Google Code was very barebones, but in a sense that was its charm. I like BitBucket and CodePlex too, but for small projects Google Code was just fine. Especially since I’ve shut down those projects. However, now I need to make a choice: do I put effort in moving my discontinued projects? And if so, do I move them to another Hg provider, or do I bite the bullet and convert them to Git?

Guess I’ll bite the bullet. Let me do so right now, and get back in a fresh post with the results…