Speaker Tips – Bootstrapping Conference Speaking

Photo of Trisha and Daniel presenting at Devoxx

I have loads of advice for aspiring speakers, which is lucky because I get asked about how to get started (or how I got started) all the time. I found an email I sent to someone absolutely years ago (2014) and thought it useful enough to dust off and post. It's interesting to see my mindset back then because now I've largely forgotten what it was like in the early days.

The timing is not great, since in these Coronavirus times no-one's going to or presenting at conferences, but I firmly believe that with all these virtual events and conferences there's a much lower barrier to entry to speaking, and that now is exactly the right time to start presenting if it's something you've ever had on your wish list.

"I was hoping I could get some advice off you as I'm starting to look at ways to get out and speak a little bit more at events. Would you have some insights from how you started?"

Continue reading "Speaker Tips – Bootstrapping Conference Speaking"

Speaker Tips – What to Wear

For years I’ve avoided talking about the topic of what to wear when presenting. I didn’t want to cover it because I didn’t want people to think that I only worried about this topic because I was a woman. I also didn’t want other women to inherit any of my neuroses around deciding what to wear. I’m the sort of person who always enjoyed thinking long and hard about what to wear the next day at work, and I know that’s not how everyone works.

Continue reading "Speaker Tips – What to Wear"

Speaker Tips – Wearing a Roaming Mic is More Complicated Than I Realised

Photo of Trisha presenting at Devoxx

I realise I have a bunch of experience and advice for speakers and potential speakers that I simply haven’t written down or shared. Here’s the first piece on things to consider that you might not have thought about.

Note: as usual, my advice is from the point of view of a woman (me) and is aimed mostly at women, but also as usual it’s probably useful for others to know too.

Continue reading "Speaker Tips – Wearing a Roaming Mic is More Complicated Than I Realised"

New IntelliJ Tricks I Learnt Part 2

Apparently, I’m all about Continuous Learning - after I wrote the last post about IntelliJ Tips, I carried on through my trawl of the documentation and, of course, discovered a load more things I didn’t know. And this is all just in the Quick Start section!

So here’s the next batch (although once again I’m not sure how many are only applicable to IntelliJ 14). All shortcuts are for Windows unless otherwise stated, and Mac users should be able to replace the Ctrl key with Cmd in all these cases.

Navigate between methods

Now I knew you could use the structure thingie (Ctrl+F12) to let you navigate to methods in your class (although I never actually use it, it somehow never sticks in my head). What I did not know is that you can jump between methods using Alt+Up/Down arrows. This strikes me as being super useful, especially to browse tests.

Refactoring String Fragments

I’ve wanted this feature so many times, but could never find it or get it to work - did you know you can refactor out parts of a hardcoded string into variable/field/constant? Select the section of the String you want to extract, and use the normal “Extract…” shortcuts - e.g. Ctrl+Alt+V to extract it into a variable.

I’m sure I’ve tried this before and it didn’t work. But I’ve tested it and it does!

Invert Boolean

There doesn’t seem to be a keyboard shortcut mapped by default, but using “Refactor -> Invert Boolean…” (or using our newly discovered “Navigate to Action” shortcut of Shift+Ctrl+A and typing “Invert”) you can tell IntelliJ you want a boolean field to mean the opposite thing, and it will flip the meaning everywhere. For example, you might have an saved flag, and you now want it to mean notSaved - IntelliJ will make sure the isSaved method returns !notSaved.

Magic Refactor Suggestions

You don’t always know exactly what refactoring operation you want to perform, and IntelliJ is ready to help - it can suggest refactorings available in the current context using the catchy magic incantation Ctrl+Shift+Alt+T. Seems useful, but I’m pretty sure I’m not going to remember that one.

Highlight implemented/overridden methods

I love everything about IntelliJ’s ability to find usages of things - finding where methods are called, finding implementations of a method, highlighting usages of a field, method or variable… What I didn’t know, is that you can highlight the methods that implement or override a specific interface or superclass. For some people, this might not add much, as your little “I override something” icon

"Overrides

combined with the @Override annotation, might tell you all you need to know. But that only really works if you’re implementing a a single interface. If you’ve correctly separated your concerns, you might implement several interfaces, and want to know which are the methods from a particular one. That’s where Shift+Ctrl+F7 on the “extends” keyword comes in handy.

Run individual inspection by name

I use inspections quite a lot. They’re especially useful if you have a codebase that doesn’t quite conform to your ideal standards, so you can’t yet turn on automated checks like checkstyle to break the build when the code doesn’t conform - there’s an initial step where first you need to clean up the code. Inspections are great, because you can have IntelliJ give you little yellow marks to show where things are suboptimal, and aim to check in only files without little yellow marks.

What I didn’t know, is that you can run a single inspection on files in any scope. So if, for example, you wanted to make sure that the code you’ve touched in this change has no unused bits, like unused parameters or unused/untested methods, you could press Shift+Alt+Ctrl+I and type “unused”. Select the “Unused Declaration” inspection and choose to run this on all uncommitted files. This will tell you where you can clean up your code, and every commit should make your codebase that little bit better.

Saving Power With Highlighting

I did not know you could easily alter the active errors/warnings, and use that to save power. Quite Interesting.

Auto indent your lines

I almost obsessively reformat my code as I go, pressing Ctrl+Alt+L almost like a muscle twitch. What I’ve just discovered, though, is that there’s a shortcut which will just fix the line indentation, which is probably 80% of what I need anyway - Ctrl+Alt+I.

Fix Evil String Concatenation

I can’t believe I didn’t notice this one earlier - do you know how many times I’ve gone around and manually changed:

System.out.println("This thing " + something + " is " + somethingElse); 

to

System.out.printf("This thing %s is %s%n", something, somethingElse); 

Do you??? Anyway you don’t need to - Alt+Enter inside the params will suggest the replacement and do it for you. Nice.

VCS Quick Access

One of the areas where I definitely don’t use IntelliJ to the best of its abilities is the Git integration. I’ve been using SourceTree combined with IntelliJ to do most of my VCS management (I’m so sorry, I’m just not a command line person, I need to actually see it). With the new laptop, I haven’t installed SourceTree yet and I’m going to try and do everything via the IDE. Previously I used the right-click menu mostly for managing VCS operations, occasionally the VCS menu, and did most stuff in the “Changes” window. But now I’ve discovered Alt+"Back Quote” (Ctrl+V on the mac) to bring up the menu of git-shaped operations for this context. To stop you having to hunt all over the keyboard to find what on earth a “Back Quote” is, it’s `, which on both my UK and US (Windows) keyboards is in the top left corner of your keyboard (on the Mac, it’s on the bottom left next to the shift, but you shouldn’t need it since your shortcut is different anyway).

Amend Commits

I’ve just discovered that you can commit a change which smushes up into your last commit and fixes it. I’m assuming it commits the new changes and (potentially) an updated commit message into the last change. I really wish I’d known about this earlier, on a number of occasions in the last few months I’ve done this either manually or by doing a rather dangerous soft reset. I will definitely be using this in the future.

"Amend

The Cursor as a Breakpoint

Did you know that you can use the cursor as a temporary breakpoint? I did not. Well, now you know.

Labelling Changes

I hope by now none of us developers are doing that icky thing of having “Copy of…” and “Backup of…” filenames and directories to keep track of our versions. We’re all using a VCS of course. But if you’re being strict about making sure that every commit leads to a working build (we all do that, right…?) then sometimes even distributed file systems like git, with its local branches, are too heavyweight for experiments and debugging.

IntelliJ has Local History, which I personally think you should never rely on, but has occasionally saved my bacon in times of strife. It also does this really nice thing (automatically) where it labels versions where the tests passed, so you’ve got some level of confidence that at that point in time, at that revision, things weren’t hideously broken. At the very least, they must have compiled. What I did not know is that you can add your own labels, so you could label some local, non-committed version of the file as “feature x works but y doesn’t” (or probably something much shorter).

I think it looks useful. As I say though, not a replacement for VCS, but a suppliment.

So, that's the end of Week One at JetBrains, and already I've learnt a whole heap of things. I'm sure there's more to come, so stay tuned!

New IntelliJ Tricks I Learnt Today

Day three of my brand new job - woohoo! One of my first tasks is checking the documentation of IntelliJ, since I’m already a “Power User”, to see if there’s stuff missing that someone like me might want to see. Firstly, a confession - I’m not sure I’ve actually read the IntelliJ documentation before. I mean, really read it. Of course, I’ve dipped into it when I needed to know something, I’ve searched for help with specific items, but like many developers, I tend to use something first rather than read the documentation first.

But I’ll tell you what, today I’ve learnt a whole bunch of useful things IntelliJ can do that I hadn’t previously known, and they’re the sorts of things you would only stumble over if a) you read the docs (pah!) or b) you watched someone else using the tool and saw them doing something you didn’t know was possible.

So here’s today’s list, and feel free to laugh at me and be smug in my direction if you already knew these things (note: I have upgraded to IntelliJ 14, and at the time of writing I don’t know which of these features are new and which are simply previously undiscovered):

Navigate directly to an action or option

Press Shift+Ctrl+A (Windows) or Shift+Cmd+A (Mac) and start typing the name of the thing you want to do, or the setting you want to change. I’ve found this especially useful now I’m back on Windows and I don’t have that nice helpful typing box on the help menu that will take me straight to the menu item I want. But what’s most useful about this for me today, as I’m setting up a new profile on a new laptop (more on the new laptop later, if it doesn’t defeat me utterly) is that from here, you can turn various settings on and off without having to navigate through the settings screen:

<img src="https://trishagee.github.io/static/images/stuff_i_learnt_about_intellij/action.png&#34; alt="Navigate to Action" title="Navigate to Action">

Statement completion

I never knew there was a shortcut for finishing off a statement, all that Java boilerplate you need to keep the compiler happy - semi colons and curly brackets and everything. But there is, and I can see it being super useful, especially if you’re using other bits of IntelliJ code completion to create the core of your line of code.

Issue tracker integration

I’m sure loads of people are already using integration with their favourite issue tracker, but I hadn’t really thought about this as something that I really cared about. But I was watching the intro videos for YouTrack (not surprisingly I’ll be using this instead of Jira during my time at JetBrains) and when I saw how the IDE integration worked, I suddenly realised how this small thing can add up to save thousands of keystrokes over time, not to mention saving precious navigational seconds and window-switching.

For me, just the ability to generate at least the start of the commit message is a saving in time, and adds to project consistency if all your developers are doing the same thing. On my last project we only just realised we all quoted the Jira issues in subtly different ways.

Settings shortcut keys

When I initially started using IntelliJ in anger back in 2008, I was very much a point-and-click type user. Over time, pair programming with keyboard-super-users and giving live demos with very limited time available, I’ve worked harder to become a keyboard-shortcuts person. With the latest version of IntelliJ, I can’t find the tiny icons I use to get to the settings window, something that I’ve been using a lot as I set up the new IDE instance on the new laptop. So I bit the bullet and learnt the keyboard shortcuts, and it’s already saving me a bunch of time (on the rare occasions when the aforementioned “Navigate to Action” fails me).

Ctrl+Alt+S for the settings dialog (appears to be Cmd + , on the Mac) Shift+Ctrl+Alt+S for the project structure dialog (appears to be Cmd + ; on the Mac)

<img src="https://trishagee.github.io/static/images/stuff_i_learnt_about_intellij/settings.png&#34; alt="Settings Shortcuts" title="Settings Shortcuts">

Yeah. I can’t believe I wasn’t already using those either.

Selecting the negative

I use completion/suggestions all the time from IntelliJ, I’m far too lazy to type everything. What I didn’t realise, is that you don’t just have to accept the default they give you. If, for example, IntelliJ suggests a boolean value, you can get it to negate that value by selecting it with “!” instead of enter or tab. Yes, I know I’ve done a horrible job of explaining that, but take a look at the documentation and try it, it’s quite cool.

Exclude from Autocomplete

Speaking of code completion, sometimes IntelliJ is sometimes just a bit too keen to suggest something, and you really will never want that value. In the past, I’ve always used Settings -> Editor -> General -> Auto Import to manage the suggestions (the most common one for me is I will never want java.awt.List, I will almost always want java.util.List). Well, you don’t have to go into settings to do this, you can do it from the suggestions themselves - navigate to the item you don’t want (in my case, java.awt.List) and press Alt+Enter, this will give you the option of excluding this from the suggestions in the future.

That’s what I found from just one day of browsing the documentation and setting up my IDE from scratch yet again. Maybe I’ll promptly forget all these, or maybe they’ll be new weapons in my armoury of IDE-fu. Either way, maybe one or two people will find this useful.

Using Groovy to import XML into MongoDB

This year I’ve been demonstrating how easy it is to create modern web apps using AngularJS, Java and MongoDB. I also use Groovy during this demo to do the sorts of things Groovy is really good at - writing descriptive tests, and creating scripts.

Due to the time pressures in the demo, I never really get a chance to go into the details of the script I use, so the aim of this long-overdue blog post is to go over this Groovy script in a bit more detail.

Firstly I want to clarify that this is not my original work - I stole borrowed most of the ideas for the demo from my colleague Ross Lawley. In this blog post he goes into detail of how he built up an application that finds the most popular pub names in the UK. There’s a section in there where he talks about downloading the open street map data and using python to convert the XML into something more MongoDB-friendly - it’s this process that I basically stole, re-worked for coffee shops, and re-wrote for the JVM.

I’m assuming if you’ve worked with Java for any period of time, there has come a moment where you needed to use it to parse XML. Since my demo is supposed to be all about how easy it is to work with Java, I did not want to do this. When I wrote the demo I wasn’t really all that familiar with Groovy, but what I did know was that it has built in support for parsing and manipulating XML, which is exactly what I wanted to do. In addition, creating Maps (the data structures, not the geographical ones) with Groovy is really easy, and this is effectively what we need to insert into MongoDB.

Goal of the Script

  • Parse an XML file containing open street map data of all coffee shops.
  • Extract latitude and longitude XML attributes and transform into MongoDB GeoJSON.
  • Perform some basic validation on the coffee shop data from the XML.
  • Insert into MongoDB.
  • Make sure MongoDB knows this contains query-able geolocation data.

The script is PopulateDatabase.groovy, that link will take you to the version I presented at JavaOne:

"PopulateDatabase.groovy"

Firstly, we need data

I used the same service Ross used in his blog post to obtain the XML file containing “all” coffee shops around the world. Now, the open street map data is somewhat… raw and unstructured (which is why MongoDB is such a great tool for storing it), so I’m not sure I really have all the coffee shops, but I obtained enough data for an interesting demo using

http://www.overpass-api.de/api/xapi?*[amenity=cafe][cuisine=coffee_shop] 

The resulting XML file is in the github project, but if you try this yourself you might (in fact, probably will) get different results.

Each XML record looks something like:

<node id="178821166" lat="40.4167226" lon="-3.7069112">     <tag k="amenity" v="cafe"/>     <tag k="cuisine" v="coffee_shop"/>     <tag k="name" v="Chocolatería San Ginés"/>     <tag k="wheelchair" v="limited"/>     <tag k="wikipedia" v="es:Chocolatería San Ginés"/> </node> 

Each coffee shop has a unique identifier and a latitude and longitude as attributes of a node element. Within this node is a series of tag elements, all with k and v attributes. Each coffee shop has a varying number of these attributes, and they are not consistent from shop to shop (other than amenity and cuisine which we used to select this data).

Initialisation

<img src="https://trishagee.github.io/static/images/GroovyScript1.png&#34; alt="Script Initialisation" title="Script Initialisation">

Before doing anything else we want to prepare the database. The assumption of this script is that either the collection we want to store the coffee shops in is empty, or full of stale data. So we’re going to use the [MongoDB Java Driver] (http://docs.mongodb.org/ecosystem/drivers/java/) to get the collection that we’re interested in, and then drop it.

There’s two interesting things to note here:

  • This Groovy script is simply using the basic Java driver. Groovy can talk quite happily to vanilla Java, it doesn’t need to use a Groovy library. There are Groovy-specific libraries for talking to MongoDB (e.g. the MongoDB GORM Plugin), but the Java driver works perfectly well.
  • You don’t need to create databases or collections (collections are a bit like tables, but less structured) explicitly in MongoDB. You simply use the database and collection you’re interested in, and if it doesn’t already exist, the server will create them for you.

In this example, we’re just using the default constructor for the MongoClient, the class that represents the connection to the database server(s). This default is localhost:27017, which is where I happen to be running the database. However you can specify your own address and port - for more details on this see Getting Started With MongoDB and Java.

Turn the XML into something MongoDB-shaped

<img src="https://trishagee.github.io/static/images/GroovyScript2.png&#34; alt="Parse & Transform XML" title="Parse & Transform XML">

So next we’re going to use Groovy’s XmlSlurper to read the open street map XML data that we talked about earlier. To iterate over every node we use: xmlSlurper.node.each. For those of you who are new to Groovy or new to Java 8, you might notice this is using a closure to define the behaviour to apply for every “node” element in the XML.

Create GeoJSON

<img src="https://trishagee.github.io/static/images/GroovyScript3.png&#34; alt="Create GeoJSON" title="Create GeoJSON"> Since MongoDB documents are effectively just maps of key-value pairs, we’re going to create a Map coffeeShop that contains the document structure that represents the coffee shop that we want to save into the database. Firstly, we initialise this map with the attributes of the node. Remember these attributes are something like:

<node id="18464077" lat="-33.8911183" lon="151.1958773"> 

We’re going to save the ID as a value for a new field called openStreetMapId. We need to do something a bit more complicated with the latitude and longitude, since we need to store them as GeoJSON, which looks something like:

{ 'location' : { 'coordinates': [<longitude>, <latitude>],                  'type'       : 'Point' } } 

In lines 12-14 you can see that we create a Map that looks like the GeoJSON, pulling the lat and lon attributes into the appropriate places.

Insert Remaining Fields

<img src="https://trishagee.github.io/static/images/GroovyScript4.png&#34; alt="Insert Remaining Fields" title="Insert Remaining Fields"> <img src="https://trishagee.github.io/static/images/GroovyScript5.png&#34; alt="Validate Field Name" title="Validate Field Name"> Now for every tag element in the XML, we get the k attribute and check if it’s a valid field name for MongoDB (it won’t let us insert fields with a dot in, and we don’t want to override our carefully constructed location field). If so we simply add this key as the field and its the matching v attribute as the value into the map. This effectively copies the OpenStreetMap key/value data into key/value pairs in the MongoDB document so we don’t lose any data, but we also don’t do anything particularly interesting to transform it.

Save Into MongoDB

<img src="https://trishagee.github.io/static/images/GroovyScript6.png&#34; alt="Save Into MongoDB" title="Save Into MongoDB"> Finally, once we’ve created a simple coffeeShop Map representing the document we want to save into MongoDB, we insert it into MongoDB if the map has a field called name. We could have checked this when we were reading the XML and putting it into the map, but it’s actually much easier just to use the pretty Groovy syntax to check for a key called name in coffeeShop.

When we want to insert the Map we need to turn this into a BasicDBObject, the Java Driver’s document type, but this is easily done by calling the constructor that takes a Map. Alternatively, there’s a Groovy syntax which would effectively do the same thing, which you might prefer:

collection.insert(coffeeShop as BasicDBObject) 

Tell MongoDB that we want to perform Geo queries on this data

<img src="https://trishagee.github.io/static/images/GroovyScript7.png&#34; alt="Add Geo Index" title="Add Geo Index"> Because we’re going to do a nearSphere query on this data, we need to add a “2dsphere” index on our location field. We created the location field as GeoJSON, so all we need to do is call createIndex for this field.

Conclusion

So that’s it! Groovy is a nice tool for this sort of script-y thing - not only is it a scripting language, but its built-in support for XML, really nice Map syntax and support for closures makes it the perfect tool for iterating over XML data and transforming it into something that can be inserted into a MongoDB collection.

Converting Blogger to Markdown

I’ve been using Blogger happily for three years or so, since I migrated the blog from LiveJournal and decided to actually invest some time writing. I’m happy with it because I just type stuff into Blogger and It Just Works. I’m happy because I can use my Google credentials to sign in. I’m happy because now I can pretend my two Google+ accounts exist for a purpose, by getting Blogger to automatically share my content there.

A couple of things have been problematic for the whole time I’ve been using it though:

  1. Code looks like crap, no matter what you do.
  2. Pictures are awkwardly jammed in to the prose like a geek mingling at a Marketing event.

The first problem I’ve tried to solve a number of ways, with custom CSS at a blog- and a post- level. I was super happy when I discovered gist, it gave me lovely content highlighting without all the nasty CSS. It’s still not ideal in a blogger world though, as the gist doesn’t appear in your WYSIWYG editor, leading you to all sorts of tricks to try not to accidentally delete it. Also I was too lazy to migrate old code over, so now my blog is a mish-mash of code styles, particular where I changed global CSS mulitple times, leaving old code in a big fat mess. There’s a lesson to be learned there somewhere.

The second problem, photos, I just gave up on. I decided I would end up wasting too much time trying to make the thing look pretty, and I’d never get around to posting anything. So my photos are always dropped randomly into the blogs - it’s better than a whole wall of prose (probably).

But I’ve been happy overall, the main reason being I don’t have to maintain anything, I don’t have to worry about my web server going down, I don’t have versions of a blog platform to maintain, patch, upgrade; I can Just Write.

But last week my boss and my colleague were both on at me to try Hugo, a site generator created by my boss. I was resistent because I do not want to maintain my own blog platform, but then Christian explained how I can write my posts in markdown, use Hugo to generate the content, and then host it github pages. It sounded relatively painless.

I’ve been considering a move to something that supports markdown for a while, for the following reasons:

  1. These days I write at least half of my posts on the plane, so I use TextEdit to write the content, and later paste this into blogger and add formatting. It would be better if I could write markdown to begin with.
  2. Although I’ve always disliked wiki-type syntax for documentation, markdown is actually not despicable, and lets me add simple formatting easily without getting in my way or breaking my flow.

So I spent a few days playing with Hugo to see what it was, how it worked, and whether it was going to help me. I’ve come up with a few observations:

Hugo really is lightning fast. If I add a .md file in the appropriate place, and with the Hugo server running on my local machine it will turn this into real HTML in (almost) less time than it takes for me to refresh the browser on the second monitor. Edits to existing files appear almost instantly, so I can write a post and preview it really easily. It beats the hell out of blogger’s Preview feature, which I always need to use if I’m doing anything other than posting simple prose.

It’s awesome to type my blog in IntelliJ. Do you find yourself trying to use IntelliJ shortcuts in other editors? The two I miss the most when I’m not in IntelliJ are Cmd+Y to delete a line, and Ctrl+Shift+J to bring the next line up. Writing markdown in IntelliJ with my usual shortcuts (and the markdown plugin) is really easy and productive. Plus, of course, you get IntelliJ’s ability to paste from any item in the clipboard history. And I don’t have to worry about those random intervals when blogger tells me it hasn’t saved my content, and I have no idea if I will just lose hours of work.

I now own my own content. It never really occurred to me before that all the effort I’ve put into three years of regular blogging is out there, on some Google servers somewhere, and I don’t have a copy of that material. That’s dumb, that doesn’t reflect how seriously I take my writing. Now I have that content here, on my laptop, and it’s also backed up in Github, both as raw markdown and as generated HTML, and versioned. Massive massive win.

I have more control over how things are rendered, and I can customise the display much more. This has drawbacks though too, as it’s exactly this freedom-to-play that I worry will distract me from actual writing.

As with every project that’s worth trying, it wasn’t completely without pain. I followed the (surprisingly excellent) documentation, as well as these guidelines, but I did run into some fiddly bits:

  1. I couldn’t quite get my head around the difference between my Hugo project code and my actual site content to begin with: how to put them into source control and how to get my site on github pages. I’ve ended up with two projects on github, even though the generated code is technically a subtree of the Hugo project. I think I’m happy with that.
  2. I’m not really sure about the difference between tags, keywords, and topics, if I’m honest. Maybe this is something I’ll grow into.
  3. I really need to spend some time on the layout and design, I don’t want to simply rip off Steve’s original layout. Plus there are things I would like to have on the main page which are missing.
  4. I needed to convert my old content to the new format
  5. Final migration from old to new (incomplete)

To address the last point first, I’m not sure yet if I will take the plunge and do full redirection from Blogger to the new github pages site (and redirect my domains too), for a while I’m going to run both in parallel and see how I feel.

As for the fourth point, I didn’t find a tool for migrating Blogger blogs into markdown that didn’t require me to install some other tool or language, and there was nothing that was specifically Hugo-shaped, so I surprised myself and did what every programmer would - I wrote my own. Surprising because I’m not normally that sort of person - I like to use tools that other people have written, I like things that Just Work, I spend all my time coding for my job so I can’t be bothered to devote extra time to it. But my recent experiences with Groovy had convinced me that I could write a simple Groovy parser that would take my exported blog (in Atom XML format) and turn it into a series of markdown files. And I was right, I could. So I’ve created a new github project, atom-to-hugo. It’s very rough, but a) it works and b) it even has tests. And documentation.

I don’t know what’s come over me lately, I’ve been a creative, coding machine.

In summary, I’m pretty happy with the new way of working, but it’s going to take me a while to get used to it and decide if it’s the way I want to go. At the very least, I now have my Blogger content as something markdown-ish.

But there are a couple of things I miss about Blogger:

  1. I actually like the way it shows the blog archive on the right hand side, split into months and years. I use that to motivate me to blog more if a month looks kinda empty
  2. While Google Analytics is definitely more powerful than the simple blogger analytics, I find them an easier way to get a quick insight into whether people are reading the blog, and which paths they take to find it.

I don’t think either of these are showstoppers, I should be able to work around both of them.