Practicing Oracle12c migration made simple

My professional experience with Oracle is that there is no "5 minute introduction tutorial". That means you need to be serious about getting started with Oracle (or just try out a new feature) because things won't get smooth until you pass the entry barrier of installing and configuring Oracle.

Sadly, this experience results in

1. Developers that are used to more lightweight persistence layers just...don't get started with Oracle ("Meh, let´s try MongoDb or Elasticsearch instead")
2. Database Administrators that would benefit from keeping up with the latest features...just skip it because it's too cumbersome to get an isolated playground Oracle DB up and running

What can we do to lower this entry barrier? Vagrant to the rescue! Over the past weeks i contributed to the GitHub repository wkoertgen/train.oracle12.migration whichs aims to alleviate most of the nastyness of setting up Oracle. It is also a great resource on installation and configuration.

hello.nVLC: A minimal WPF Media Player

A few days ago, i put hello.nVLC on GitHub. This is a minimal WPF media player application comparing an MVVM media player implementation for Windows Media Player and VLC using

• nVLC, a great managed wrapper for VLC by Roman Ginzburg, 
• VLC.Native, a NuGet package containing the native VLC dependencies and
• FontAwesome.Sharp, our WPF wrapper for using awesome icons.

Vagrant: Optimizing virtual Ubuntu/Debian boxes

A while ago, we used hilverd/vagrant-ubuntu-oracle-xe to alleviate the testing bottleneck, i.e. too many developers on too few dedicated testing environments. Since then, i am a big Vagrant fan as this really boosted up our testing feedback cycle time.

However, even oracle-xe is anything but a lightweight installation, so minimizing your base box is a good thing to do.

There are quite a few resources on how to optimize virtual boxes for vagrant. I picked up some of these and documented what worked well in this gist mkoertgen/vagrant_export_vbox_vm_basebox.md. Enjoy!

Squirrel.Windows - Starterkit

You probably know Slack, the team communication tool. If not, go see. It's awesome. The Slack windows app is one of the most prominent users of Squirrell for installation & update. Squirrel itself is an ingeniously simple library for installing and updating desktop windows applications. It uses NuGet packaging to build app releases and supports delta compression for updates. You don't need a NuGet feed to host your releases, just a static web server. If you want to try out Squirrel, you may have a look at the starter sample mkoertgen/hello.squirrel i comitted today. It's a minimal WPF application with an update button.

As extra candy i automated "releasifying" updates with msbuild, i.e. you can build updates by typing

    build.bat HelloSquirrel\HelloSquirrel.csproj /t:Deploy /p:DropLocation=c:\temp\Releases

Enjoy!

Faceted Search using Elasticsearch and WPF

Today i uploaded a quick sample on how to build faceted navigation for Elasticsearch in WPF which includes highlighting of search results. Below is a screenshot of the sample app. Enjoy!

Work tip: Disable Chrome history

If you are using Google Chrome at work you should probably disable storing history to avoid your intranet urls being synced out into the Google cloud. Here is how: How to Prevent Google Chrome From Storing Browser History. Chrome basically stores history and other data in a local SQLite database. The tip is a little bit of a hack: You first empty the database (clear history) and then prevent Chrome to modify it (by making it read-only).

When to use git-flow and GitHub Flow

Some people ask how good git-flow matches with the practice of continuous integration. In 2011, Scott Chacon from GitHub Inc. wrote a post on exactly that: GitHub Flow.

For the last few weeks we switched from git-flow to GitHub Flow - on GitHub as well as on our gitblit-Server (needs gitblit tickets, v1.4+).

Working both with GitHub Flow vs. git-flow taught us a lot. Well, the direct ticket integration alone is a big win compared to manually keeping commits and tickets consistent, i.e. basically pasting a lot of links in each of them. Apart of that, without surprise we came to the same conclusions as Scott Chacon, i.e.:

• For continuous deployment projects, github flow is way more effective because you can have dozens of commits each day going directly into production. The many branch transitions required in git-flow quickly become a bottleneck and lose their worth as quality gates. The similar holds for small projects or simple software components where git-flow is just too big a framework.


• For products with greater release cycles (weeks or months) git-flow makes sense. Example scenarios are concurring milestones (hotfix from production vs. feature for next version) or just bigger quality gates, i.e. a commit should not or can not be directly deployed to production.