Tag: Google Code

A New Hope

Jeroen

Did I mention before that I write here to collect my thoughts and as writing practice? Well, in any case, after my previous monster post, and given that it’s the start of a new year, I figured I’d do a “New Beginnings” post. Then the sci-fi addict in me awoke and typed “A New Hope“, even though I’m a Trekkie at heart. But I digress.

I wanted to summarize which technologies and experiments I’m most interested in pursuing next. Let me try to list them in order of current preference.

1. Elasticsearch …. and Nest?

Elastic as a (primary?) data store intrigues me. It feels like a second chance for Lucene towards me (experimenting with Solr didn’t “click” for me). There recently was a major version released so it seems like a great time to start investigating. I’m hesitant about Nest though, which you’d kind-of have to use if you want to access Elastic with .NET: during my first few experiments I felt like I was “wrestling” the API.

2. Gulp, or: More Gulp!

I’ve done quite some work with Gulp recently, and it was a very (and surprisingly) fun experience! In the past, most devops tasks felt like chores to me, but not so much with this Gulp. So this point would actually be “More Gulp” (as I’ve done quite a bit of it recently already), but I still have quite a list of things I want to try out, like for instance setting up JSCS.

3. Node

Yes, yes, I know: I’d be a hipster-after-the-fact if I’d start on Node now. Even so, I enjoy writing Javascript, and Node would be a way to do even more of it in my pet projects. Not sure how I would be utilizing Node yet: with ExpressJS, for custom (Gulp) packages, general scripting, or perhaps something like project Euler.

4. Linux

This one’s been on my mind for a while now: perhaps I’ve been stuck too much in my Windows-comfort-zone. It would be good to shape up my base knowledge of Linux as a development environment.

5. Grunt

Why yes, in addition to Gulp there’s also Grunt on this list. Gotta know what’s on the other side of the fence to be able to compare, right?

I’m placing a short but distinct separation here, because these are currently mostly “in reserve” kind of ideas.

6. Couchbase

Working a little with this at work as well. There’s a few things I’d be excited about to try at home, mostly features from version 3 and 4. Would need a “subject” though to make it interesting…

7. Study three-way-diff-tools

For some reason I never got my mind wrapped around these tools. And that’s frustrating. I should just spend a few hours trying to understand the details of these tools… I guess.

8. Raspberry / something IoTish

This one’s on the list because it nags me that I don’t see what all the rage with IoT is (or is it “was”?) about, and for that reason I feel like I have to “make Slackbot call a webhook that calls my webserver that calls my Raspberry which turns on a LED strip and autopilots a drone around in my room”. Or something.

9. Android app

I’m curious how the Android-dev-experience compares to my short experiments from around 2011. This would also allow me to revisit Java. But on a whole I feel I’d have to invest a lot of time or not do this one at all.

10. Closure Compiler

It’s on the list because I find the idea of it intrinsically interesting. It’s low on the list because I’m not sure if I work on things personally or professionally at the moment where this would be worth the investment.

Wow, that worked like a charm! Apologies for the stream-of-consciousness post, but now I do know what to do next! And I’m not even going back to adjust the (order of the) list accordingly, I’m just gonna leave you all hanging out there, guessing at what’s next…

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…

BattleTop

Jeroen

Exactly one month ago I wrote about Google Code hosting. At the time I wasn’t ready to divulge the project I was using to test it, but today’s different. Today, I have decided to put BattleTop in Beta!

BattleTop is a responsive single-page web application to assist in bookkeeping things like Characters, Initiative, Hit Points, Conditions, et cetera, during D20-based table top RPG sessions.

BattleTop Beta Logo
BattleTop Beta Logo

You can view it, clone it, and provide pull requests for it at Google Code. Mind you, it is still in beta, meaning there’s many rough edges and bugs to be found. I have been and will be dogfooding it during our own table top RPG sessions, so I’ll be sharing your frustrations about bugs and time permitting I will be fixing things.

The current list of features:

  • Track characters. Add and remove monsters, NPCs, PCs, and environment initiatives. You can also reset the list to the party, or to a blank, new list.
  • Track initiative. Keep initiative and initiative modifiers, sort the list by initiative, keep track of ready and delay actions.
  • Track conditions. Each character has its own list of conditions which you can add, remove or change, with a number of turns to it (so they wear off automatically).
  • Track hit points. Each character optionally has a number of hit points. You can deal damage or apply healing to change the hit point amount.
  • Save/Load. Using the LocalStorage API BattleTop will save your state every 5 seconds. If you navigate away or re-open the page on your next play session the old state will be there.

Note: because BattleTop extensively uses many modern features (html5 semantic markup, css3 features, modern JS such as LocalStorage), only modern browsers will be supported.

Here’s a general view of what it currently looks like:

 

BattleTop 0.9.0 Setup Mode
BattleTop 0.9.0 Setup Mode

 

BattleTop 0.9.0 Update Hit Points
BattleTop 0.9.0 Update Hit Points

The horrifying state of free Android initiative-keeping apps was what triggered me to create BattleTop. I’ve decided on a HTML5 app as opposed to a native app because (a) it would be easier for me to create something in a short amount of time, and (b) to keep it portable across devices and operating systems with little effort. Hopefully BattleTop will help or inspire others as well.

Google Code Hg Hosting

Jeroen

A few months back I wrote a short comparison of Hg Hosting Providers, followed by a post about CodePlex Hg Hosting. In the mean time I’ve also tested creating a Bitbucket project, but I’ve neglected writing a post about the experience. I may get back on that some time, but first I would like to share my more recent experience with Google Code.

Note that I’m not ready (read: “proud enough”) to share the actual project I’m hosting, as it’s still in (and may never leave) prototype status. Once it’s worth viewing, I’ll probably be doing a short blog post about the project itself.

Without further ado, let’s jump in!

Sign Up and Project Creation

In this case I’m not writing much about sign up. You need a Google account, which most folks will probably already have. If, like me, you are already signed in to your account, nothing more is needed here.

On to project creation, which was surprisingly simple. The process is one step total:

Creating a Google Code Project
Creating a Google Code Project

Very similar to the CodePlex project creation. To note the differences:

  • It’s not entirely clear in Google Code how the project name would become part of the project URL.
  • Source control at Google Code (understandably) excludes TFS.
  • Google Code asks you to label (tag?) your project at creation time.
  • Most importantly: Google Code requires you to pick a license at project creation time.

That last one is really the only difference from CodePlex, but a big one at that! With CodePlex you get a one-month “Setup Mode“, which means your project is private and you can still work out the details (including picking an appropriate license). This is a big plus for CodePlex, especially if (like me at the time) you’re creating your first open source project.

Importing the Existing Repository

Where I had some cautionary steps importing my existing repository the previous time around, this time I had only one, making a total of four steps to get my existing repo pushed to Google Code:

  1. Create a temporary “copy-paste-backup” of my (existing) repo folder.
  2. Clone the Google Code (empty) repo locally.
  3. Copy the existing repo into the empty repo.
  4. Push the repo.

Step one turned out to be superfluous. So, this is in fact easy as pie.

Google Code Features Overview

Here’s my first impression of the various features of a Google Code project:

  • Project home is what you see when you land on the URL of your project (which is in the format: http://code.google.com/p/project-name)
  • Downloads is where you can host releases you’ve built and packaged. Haven’t tried this feature yet, but it looks very straightforward.
  • Wiki feels a little odd, because you start at a table-based listing of all pages. Beyond that it’s just a basic wiki (with yet another syntax), that’ll do the job.
  • Issues are for tracking bugs and tasks. Haven’t tried this yet, but it looks both straightforward and barebones.
  • Source provides a way to browse the files, view a history of the changes, and check on any clones there may be. Not as fancy as -say- GitHub, but gets the job done.
  • Administer allows you to change just about everything you see in your project, and works quite okay.

The theme should be clear: everything in Google Code is no-nonsense. All important features for code hosting are there though.

Conclusions

This hosting provider is pushing the KISS principle to the max. Google Code gets the job done, but it is very barebones, at times even downright ugly. Great hosting, but it doesn’t leave me “WOWed”. With the same functionality but a more pleasant experience, I think I would prefer CodePlex.

Comparing Hg Code Hosting Providers

Jeroen 2 Comments

Mercury ElementMost usually, I’m a very organized person. Even before I was programming (when I was making Hero Quest maps in Q&A and WordPerfect) I would still want periodic backups of my data. Given all that, I’ve remained remarkably oblivious of Version Control for quite a long time. Here’s an overview of my VCS history:

  • 1990 – 1992 Derp derp, playing Commander Keen and friends.
  • 1992 – 2003 Copy-paste-style backups, periodically.
  • 2003 – 2005 Visual Sourcesafe. The horror…
  • 2005 – current SVN and TortoiseSVN. Much better!
  • 2011 – current Mercurial (with TortoiseHg), and a dash of Git.

On a coding project with friends, one of them suggested we’d use one of the DCVS systems: either Hg or Git. After a short debate (and after reading endless flamewars between the two) we decided on trying Hg. My “re-education” started with reading the HgInit tutorial by Joel Spolsky. Here’s a quote that stuck with me:

It turns out that if you’ve been using Subversion, your brain is a little bit, um, how can I say this politely? You’re brain damaged. No, that’s not polite. You need a little re-education.

True as it is.

To be honest though: I still don’t mind using SVN. At work we have an existing repository from which we’ll probably not be switching, and it even has some advantages over Hg. However, for any new project I would choose a DCVS, either Git or Hg, depending on the circumstances.

So for my latest pet project I’ve started a Hg repository as well. So far I’ve just been committing locally, using it as a backup and history mechanism. However, with friends and family joining on the project I will probably be moving the repository to an Open Source Hosting Provider. There’s a few that came to mind, and I’m currently considering four of them. Even though there’s a decent Wikipedia comparison article, I still decided to make my own comparison table with features I find interesting:

Google Code Bitbucket CodePlex SourceForge
Source Control Hg, Git, SVN Hg, Git Hg, Git, SVN, TFS Hg, Git, SVN
Issue tracker Custom JIRA Custom Custom
Wiki MoinMoin-based markdown Creole-based markdown Yes Daring Fireball-based markdown
Forum No No Yes Yes
Private projects No Yes No No
Licenses Any, single-licensed ? 10 OS licenses available Any OS license
Authentication Google Account Bitbucket account Codeplex + optional Win. Live SourceForge account
Projects 250,000+ 93,000+ 28,000+ 350,000+

Currently I’m leaning somewhat towards CodePlex, for no particular reason or rationale. Or perhaps I’ll end up trying them all before deciding. Either way, I’ll sleep another night on it, for now.