maplesteve.com

Insert timestamps into Jekyll pages

2014-01-25T00:00:00+00:00

Though my Jekyll setup runs perfectly smooth, I wanted to have some kind of control, if (all) pages are re-generated when I make changes to the CSS or other minor things that aren’t immediately visible.

So I wanted to have a timestamp of the page generation. To have re-usable code, I was looking for a custom Liquid tag for that purpose and found a gist by blakesmith: render_time.rb.

Since I wanted the timestamp only as a comment in the HTML pages, I made a small change. Besides that, it’s the same - so thanks a lot blakesmith!

Here’s render_time.rb:

module Jekyll
  class RenderTimeTag < Liquid::Tag

    def initialize(tag_name, text, tokens)
      super
      @text = text
    end

    def render(context)
      "<!-- #{@text} #{Time.now} -->"
    end
  end
end

Liquid::Template.register_tag('render_time', Jekyll::RenderTimeTag)

Just drop it in your _plugins folder and add the line (enclosed in Liquid open and close tags; which I can’t do here, because the Liquid tag would then be executed… :-/)

render_time Page generated at:

to e.g. your default.html.

maplesteve.com now powered by Jekyll

2014-01-19T00:00:00+00:00

I write blog post now for more than five years. One thing that I observe - like any other person on the net who blogs - is that I blog less often than I want to.

Why is that? I assume it’s when the ‘process’ is cumbersome, you’ll blog less. Especially when it comes to write short posts about this and that. (Amateur) blogging should be easy and not a multi-step login-create-publish-admin job.

I tried different engines in the past; from hand-made HTML, via Wordpress to secondcrack lately. Now I reached the next stage: Jekyll.

Jekyll brings everything I want:

understands Markdown files: Markdown makes WYSYWIG editors obsolete. All you need is a simple text editor and you can write blog posts. In my setup it’s the really great MarkdownPro.
generates static pages: In the not too distant past, dynamic web sites where state of the art. Today we know, that (at least) for blogs you don’t need all the stuff that PHP gives you. And for the rest, there is still JavaScript. Static web sites do their job without putting any pressure on the system. You don’t have to fear memory limits, CPU load or the like.
processes text files: I don’t want to use a browser to write a blog post. I want to write a text file and save it to a synced directory. Since I run an owncloud instance for various other stuff, it was really easy to create a new directory, let owncloud do the syncing and tell Jekyll to take this as its source directory. BTW: images etc. are handled exactly the same way. Can’t be more simple.
automatically updates the site on changes: When I’m finished with writing a post, I want it to be live within seconds. I don’t want to push a repository. I don’t want to login somewhere just to hit the publish button. Too many steps. Jekyll has a --watch command which is all you need, to have it constantly watch for changes of anything in the source directory and it’ll start to (re-)generate your site.
provides a simple template system: If you want a unique layout for your Wordpress blog, you’ll face a steep learning curve. It’s no surprise, that there’s a whole industry selling professional templates for WP. Even with secondcrack - which is definitely more simple than the most other systems - I found myself investing way too much into developing scripts. Jekyll bases it’s output on Liquid tags and though I didn’t know anything about this only some days ago, I quickly felt comfortable and produced results in little time.

Jekyll is so simple and quick. Setup is done literally in minutes. Just type gem install jekyll into your terminal and you’re basically done. No database setup, no user management. Now make one or two changes in the _config.yml file, point your web-servers document root to the output directory (or vice versa), save a markdown file in the _posts directory and you’re live.

If my theory works, you’ll see some more posts on this site than in the past. So stay tuned.

Google creeps into (your) Nest

2014-01-14T00:00:00+00:00

Google buys thermostat maker Nest for $3.2 billion in cash.

In a Q&A section of the announcement post on Nest’s company blog, the new member of the Google family tries to play down the privacy concerns of it’s users that fear, that Google will know a lot of additional things about them in the near future (emphasis mine):

Will Nest customer data be shared with Google?</br> Our privacy policy clearly limits the use of customer information to providing and improving Nest’s products and services. We’ve always taken privacy seriously and this will not change.

So far, so good. But what would be, if the services integrate a Google product? Nest has an answer to that also:

Will Nest and Google products work with each other?</br> Nest’s product line obviously caught the attention of Google and I’m betting that there’s a lot of cool stuff we could do together, but nothing to share today.

In plain text: Yes, we will integrate with Google services and yes, then your data will be a part of the galactic Google database.

Remember: Google is an advertising company and makes a living from knowing as much as possible about you. So, dear Nest user, be prepared to get some advices from AdSense regarding your room temperature, or some hints about a better timing for your drive to work.

Apple WWDC 2013 - New AppleTV World?

2013-06-07T00:00:00+00:00

This years developer conference to be held by Apple beginning June, 10th is teased with a headline:

Where a whole new world is developing

Apple wouldn’t be Apple, if there wasn’t a deeper meaning in this headline. So I started to think about, what this years headline could hint us to.

Everybody talks about the known things, previews of iOS 7 and MacOS 10.9 the successor of Mountain Lion, some (minor) hardware refreshes etc. And everyone seems to be sure, that we shouldn’t hold our breath hoping for a new iPhone or iPad. What do these things have to do with the 2013 claim? Nothing.

Does the ‘new world’ mean to focus on the invasion of the iPhone into China or India, which are countries being obviously late to the iPhone party? No - we saw a China-focus in last years iOS 6. Dedicate the most import event of the Apple calendar to welcome the huge market of India? Surely not.

What actually wonders me, is that noone talks about the iWatch or Apple TV (aka iTV) in context with WWDC - o.k. iWatch seems too far away, but what about the “new world” that’s “developing” simply a new world of iOS devices, that weren’t opened for the developers until now: the Apple TV?

Therefore my money would be on the introduction of the APIs for bringing all the great content and apps to the big screen via an App Store for the Apple TV.

We’ll see.

Jenkins Plugin: Create Jira issues for failed unit tests with JiraTestResultReporter

2013-03-24T00:00:00+00:00

Update: The pluginis now available in the official Jenkins plugin repository! Details here: https://wiki.jenkins-ci.org/display/JENKINS/JiraTestResultReporter-plugin

Testing your code with unit tests is a fine thing and using a Jenkins CI server for those tests is even better. Automatically creating issues in Jira for failed tests makes the workflow complete. This is what the JiraTestResultReporter plugin for Jenkins does.

This plugin examines the build job for failed unit tests. It work by using the Jenkins internal test result management for detecting failed tests. Just let Jenkins run and report your unit tests e.g. by adding the “Publish xUnit test results report” to your build job.

If JiraTestResultReporter detects new failed tests, it will create an issue for every test case in Jira:

Installation

As long as my hosting request to get the plugin included in the official plugin repository of Jenkins CI is pending, you’ll have to either build the plugin yourself or you can download the recent snapshot:

Build yourself
- Download or clone the source code from GitHub
- cd into the downloaded directory
- execute the maven command mvn package

Download the plugin package from here.

then

Upload the built or downloaded file JiraTestResultReporter.hpi to the plugins directory of your Jenkins installation or use the plugin uploader from Manage Jenkins -> Manage Plugins -> “Advanced” tab
restart Jenkins

Usage

In the build job add JiraTestResultReporter as a post-build action.
Configure the plugin for this job. See the help boxes for details. I have the dedicated Jira user ‘jenkins_reporter’ for these kinds of automatic reports.

Build your job. If there are failed tests, the plugin will create issues for them. This will (should!) happen only once for every new failed tests; new in this case means tests that have an age of exactly 1.

Jenkins PMD analysis for Objective-C with oclint

2013-03-10T00:00:00+00:00

OCLint is a static code analyzer for C, C++ and Objective-C. You’ll find it here on GitHub.

Today the maintainer merged my pull request in which I made an additional reporter module which writes a PMD-style file.

Having that, you can let the PMD Analysis run by Jenkins reports about your coding sins.

Here’s how to set the whole thing up:

1. Setup OCLint

Get the latest source code from GitHub
Follow the instructions to build OCLint
Install it.

2. Build file for Jenkins

The invocation of OCLint is configured in a build.xml. I’ll walk you through this one.

<?xml version="1.0" encoding="UTF-8"?>
<project name="fooProject" default="build-fooProject">

<property environment="env"/>

<target name="build-fooProject" depends="prepare,oclint" />

<target name="clean" description="Cleanup build artifacts">
	<delete dir="${basedir}/build/oclint" /> 
</target>

<target name="prepare" depends="clean" description="Prepare for build">
	<mkdir dir="${basedir}/build/oclint" /> 
</target>

Standard stuff so far. Setup the project and prepare the directories.

<target name="oclint">
	<antcall target="xcodebuild-clean" />
	<antcall target="xcodebuild" />
	<antcall target="oclint-xcodebuild" />
	<antcall target="oclint-parse" />
</target>

Our oclint invocation has four steps.

<target name="xcodebuild-clean">
	<exec executable="xcodebuild">
		<arg value="-configuration" />
		<arg value="Release" />
		<arg value="clean" />
	</exec>
</target>  This ensures, that we have a clean build.
 
<target name="xcodebuild">
	<exec executable="xcodebuild" output="xcodebuild.log">
		<arg value="-configuration" />
		<arg value="Release" />
		<arg value="-arch" />
		<arg value="armv7" />
		<arg value="CODE_SIGN_IDENTITY=" />
		<arg value="CODE_SIGNING_REQUIRED=NO" />
	</exec>
</target> Now we build our project. The important part is `output="xcodebuild.log"`; this will write the output to a file which will be fed to a helper script in the next step.

<target name="oclint-xcodebuild">
	<exec executable="PATH_TO_oclint-release/bin/oclint-xcodebuild" />
</target>

oclint-xcodebuild reads the xcodebuild.log and produces the file compile_commands.json. This file holds all the compiler stuff and is the input format for oclint.

<target name="oclint-parse">
	<exec executable="PATH_TO_oclint-release/bin/oclint-json-compilation-database">
		<env key="PATH" value="${env.PATH}:PATH_TO_oclint-release/bin/"/>
	 	<arg value="--" />
	 	<arg value="-o=${basedir}/build/oclint/lint.xml" />
	 	<arg value="-report-type=pmd" />
	 	<arg value="-stats" />
	</exec>
</target>
</project> Finally, this is where the magic happens. `oclint-json-compilation-database` feeds the `compile_commands.json` file to `oclint`. The `-report-type=pmd` flag tells it to use the PMDReporter, which will write its findings to a file called `lint.xml`.

Be sure to consult the documentation for OCLint and its helpers for the various arguments you can provide.

I created a gist with the whole file here.

3. Configure the job in Jenkins

Go to the configuration page of your job in Jenkins.
Add a build-step with the build.xml
Add a post-build action “Publish PMD analysis results” and enter the path to the xml file we produced. In this example it would be build/oclint/lint.xml

4. Build the job

If everything worked, you should have a new section “PMD Warnings” in your build information and after a few builds the trend chart will be produced.

Xcode & LLDB: Need to know what’s calling your method?

2013-03-08T00:00:00+00:00

Recently I wondered why a specific method gets called way more often than I would expect. I wanted to find out, which other methods call this.

The usual approach…

… would be to set a breakpoint at the beginning of the method and look at the stack trace of Xcode’s ‘Debug Session’ pane for the calling methods. Surely a tedious way. You’ll have to write down the caller and the context that led to the caller.

A better way…

… is to utilize the breakpoint capabilities of Xcode or - more specifically - of LLDB, the new debugger which comes with the new compiler CLANG. In this approach, you’ll also set a breakpoint at the beginning of the called method. Then select the breakpoint label and ctrl-click to get a small pop-up which let’s you define the behavior of the breakpoint:

Three simple things to do:

Select ‘Debugger Command’ from the ‘Action’ pop-up
Enter ‘bt 10’ into the text field
Check ‘Automatically continue after evaluating’

’bt’ is a command that LLDB understands. It’s the short for ‘backtrace’. The following number defines the number of steps the trace will have. In this case ‘bt 10’ instructs the debugger to print the last 10 method calls before it hit the breakpoint. Exactly what we need. The check we set in the third step has the simple effect, that the program keeps running, which is nice if you’re testing e.g. the GUI part of an application.

After you ran the program (don’t forget to enable breakpoints) you’ll find the logged traces in the debugger console:

* thread #1: fooApp -[WMSCollectionViewController collectionView:didSelectItemAtIndexPath:] at WMSCollectionViewController+CollectionViewDelegate.m:41, stop reason = breakpoint 2.1

frame #0: fooApp -[WMSCollectionViewController collectionView:didSelectItemAtIndexPath:] at WMSCollectionViewController+CollectionViewDelegate.m:41

#1: fooApp -[WMSCollectionViewController updateCollectionView] at WMSCollectionViewController.m:158

#2: fooApp -[WMSCollectionViewController reloadDocuments:] at WMSCollectionViewController.m:136

#3: Foundation __57-[NSNotificationCenter addObserver:selector:name:object:]_block_invoke_0

#4: CoreFoundation ___CFXNotificationPost_block_invoke_0

#5: CoreFoundation _CFXNotificationPost

#6: Foundation -[NSNotificationCenter postNotificationName:object:userInfo:]

#7: fooApp -[WMSAppDelegate checkDocumentsOpenState] at WMSAppDelegate+DocumentSetup.m:247

#8: fooApp -[WMSAppDelegate observeValueForKeyPath:ofObject:change:context:] at WMSAppDelegate+DocumentSetup.m:232

#9: Foundation NSKeyValueNotifyObserver

(I deleted some information for this purpose; so try it yourself - you’ll find a lot of useful things in there!)

So what can we learn from the output?

The first line marks the method that triggered the trace (the one, we set our breakpoint) and describes the thread which is useful if you have to wade through multi-threaded logic of your application.
As this is a trace from the viewpoint of the called method where we set the breakpoint, the frames are in reverse order. They are prefixed with frame.
Next is the framework or library the called method belongs to. In the example, there are method call from fooApp which is the example app itself or the frameworks (UIKit, Fondation, CoreFoundation etc.)
So, now we know, that initially a KVO (Key-Value-Observing) led to the call of our examined method. KVO triggered a Notification which called reloadDocuments:. In reloadDocuments: the method updateCollectionView got called and finally from that one we landed at our investigation method.
As a further convenience the file and line number from which a method are called is also printed.

Cool, eh?

Passbook: NFC ohne NFC?

2012-09-05T00:00:00+00:00

AppleInsider about an interesting approach:

Apple’s new Passbook feature in iOS 6 isn’t just a coupon app; it’s a framework that enables retailers to develop smart apps for transactions, without relying on new Near Field Communications (NFC) hardware to do so.

Install HeaderDoc on Ubuntu

2012-02-26T00:00:00+00:00

HeaderDoc is a very versatile document generation system by Apple, which can handle a wide variety of languages. The latter was the reason for me to give it a chance, since other generator either work only with a specific language or produce (for me) unusable results. HeaderDoc works fine with PHP, JavaScript etc. which makes it a perfect tool for web projects - otherwise you’ll have to deal with different tools, which can’t produce combined docs.

HeaderDocs comes with Mac OS X (at least when you have Xcode installed). But I wanted to use it on my Ubuntu server where Jenkins does all the integration stuff.

Apple has open-sourced HeaderDoc and you can find it on Apple’s open source website at http://www.opensource.apple.com/

Downlaod & unpack

The most recent version is in the Mac OS X 10.7.3 tree; copy this link and download the archive into a directory on your Linux machine: http://www.opensource.apple.com/tarballs/headerdoc/headerdoc-8.8.38.tar.gz
wget http://www.opensource.apple.com/tarballs/headerdoc/headerdoc-8.8.38.tar.gz
unpack with tar -xvzf headerdoc-8.8.38.tar.gz and cd into the created directory

Requirements

HeaderDocs is basically a PERL script, so you’ll need a recent PERL installation. This should be the case on every ‘normal’ system, so I won’t dive into installing PERL here. Besides that, HeaderDoc needs some other libraries. If they’re not installed, run the following commands:

FreezeThaw
sudo apt-get install libfreezethaw-perl
libxml2-dev
sudo apt-get install libxml2-dev
xmllint (from the libxml2-utils)
sudo apt-get install libxml2-utils
checkinstall (not necessary for this installation, but you should alway use checkinstall, when manually installing software, which circumvents the Ubuntu/Debian package system!)
sudo apt-get install checkinstall

Build & install

make clean
make - This will actually compile the software & libraries and performs a lot of tests. Three of them (‘class 3’, ‘header 5’, ‘template 1’) failed during my install, but I didn’t notice any false behaviour using HeaderDoc.
sudo checkinstall make realinstall

Ready. You should have now two files in /usr/bin/:

headerdoc2html - the processor itself
gatherheaderdoc - a utility to combine the docs in an overview

You’ll find the documentaion for HeaderDoc on Apple’s developer site

Mac OS X: WebDAV protocol not supported (solved)

2012-02-12T00:00:00+00:00

When you see in your console log messages like

11.02.12 17:36:41,009 webdavfs_agent: network_mount: WebDAV protocol not supported; file: /SourceCache/webdavfs/webdavfs-322/	mount.tproj/webdav_network.c; line: 3131

this doesn’t necessarily mean, that Mac OS X suddenly stopped understanding the WebDAV server it could mount minutes ago. In fact it’s more likely, that the problem lies on the server side and the DAV config is incomplete.

Since the Mac OS web DAV client isn’t really chatty about what’s going (wr)on(g) here, you should use a unix WebDAV client (e.g. cadaver) for debugging.

The client can properly connect to the DAV server which you can see by the result code (“200”) in the apache log file:

"OPTIONS / HTTP/1.1" 200 250 "-" "cadaver/0.23.3 neon/0.29.0"

But the client tells you, that there’s something wrong anyhow, which you can verify again in the apache log:

"PROPFIND / HTTP/1.1" 405 508 "-" "cadaver/0.23.3 neon/0.29.0"

The result code “405” means “Method not allowed”. Does the client try to talk to the DAV server via incorrect command and Mac OS therefore reports the “not supported” message? No, it’s just that the DAV server doesn’t know how to handle the DAV protocol properly.

So go and check your server config. When I upgraded Plesk from version 10.2 to 10.4, the upgrade process didn’t catch all the relevant vhost.conf files and therefore left me with a half configured DAV server. The problem is, that Plesk 10.4 uses a different directory layout under /var/www/vhosts/ and I had to manually copy and configure the vhost.conf files to their new places.