Migrating repos from Mercurial to Git can be achieved by a variety of methods. The best method I've found is to use fast-export (not HgGit), however regardless of the method they all borked the importing of my email address on commits. In this post I'll detail how to fix this.
First I performed the conversion as detailed here.
After this all my commits where shown in gitk as devnull@localhost although this only came to my attention when I tried to push to github and got an invalid-email-address error.
This can be easily fixed using the git filter-branch command:
Obviously the placeholders need to be replaced with your values.
This code is based on a stackoverflow answer but that only works for the current branch, mine applies to all branches.
Ubuntu (my distro of choice) and others are transitioning from ffmpeg to libav, libav is a fork of ffmpeg and most tools are drop in compatible, the method described in this post should work with recent versions of either, the command line tools ffmpeg and avconv are interchangeable.
Historically ffmpeg had -croptop, -cropleft etc. parameters used for cropping videos, these have now been replaced by the -vf or video filter option which is a little more complex.
The -vf option can be used to specify a section of the source video to use in the output by specifying the size and position of a rectangle to crop to:
The -vf option takes the argument crop=outw:outh:x:y - to create a new video file output.mpeg cropped to 720px x 600px and aligned 240px from the top:
In the example I'm also converting a webm video to mpeg along with cropping it, to convert webm to mpeg at the same dimensions just remove the cropping options.
A common problem when developing web applications is the ability to generate unique sequential numbers, my recent use case was an API which generated an order number on receiving an order but before the order had been stored in a database, normally I would use MySQL auto incrementing keys but I needed to send the order number back to the client long before the order was stored, as Mongodb was already in the application stack it seemed the natural place to generate a persistent source of sequential numbers.
MongoDB provides a useful function findAndModify which, while MongoDB doesn't support transactions, allows a value to be retrieved and updated atomically, making it ideal for this situation where I wanted the order number to increment by one every time it was used.
For those who're in the dark about why you'd need to retrieve and update a value in one operation, the advantage of using this over separate find and updates is that it avoids the race condition where the same value could be retrieved twice if another client attempted to retrieve the counter before the update has taken place.
The findAndModify command is no use without something to find so I started with this document (in a collection named 'Counters':
Now we have a starting point we can go onto retrieving and modifying the value, from the MongoDB command line client this be done quite simply:
The first query being the find section and the second the update, here I've used the $inc operator to increment the value by the specified number. By default this query returns the current value then updates it, if new : true.
As expected this query then returns the document and updates the value each time:
then next time....:
In the PHP driver found in the PECL repositories this command is currently not supported so must be executed using the execute() command, in my case I'm using this inside a Silex based app with the Doctrine Mongo abstraction layer (not ODM) so the syntax may be slightly different to the raw PHP Mongo library:
One thing to be careful of, which is applicable to auto incrementing in most databases, is to ensure any replication is correctly configured to ensure there is no chance of using an old value after the value has been updated elsewhere.
The article goes on to suggest this would be an ideal use case for the meter tag, however at that time it was impossible to style the meter tag to look like this. This afternoon after discovering that shadow DOM support had made it into Chrome stable I attempted to recreate the Just Giving meter using no images and without a mess of divs.
This is the result, one I'm pretty happy with, I haven't really made much attempt to style the surrounding areas, I just wanted to concentrate on the (frankly rather cool) meter:
My CSS version uses the shadow DOM to remove the default styles from the meter, colour it blue then uses a SVG mask to make the circular centre meter. The surrounding border is an SVG star rendered as the background of the element.
SVG files were generated using inkscape and can be seen in the live demo.
The percentage cannot currently be calculated using CSS, calc() doesn't work using two attr() values.
This example requires a recent version of Google Chrome
In this example I've modified the mark-up from the original example to just use one meter tag but preserved the
While this approach would not be suitable for use in a live site yet without a great deal of graceful degradation it is a very good example of the power of HTML5 & CSS3 and shows the ability they have to combine semantic mark-up and amazing presentation.
Over the past year or so there has been much hype surrounding the shadow DOM and the new options it allows for styling standard elements such as <input> or <progress>, it can be used with any element which consists of markup generated by the browser but normally hidden from view. Developers can also create shadow DOM elements too.
Until recently even where there is support for styling shadow DOM elements it has been difficult to determine what is available, however the webkit inspector in Google Chrome now has support for viewing and rendering the shadow DOM however I've found documentation on this very thin on the ground. I've tested this in the current stable branch (v19.0) on Linux, I believe the same functionality should be present across other platforms too.
Now Chrome has matured this feature has matured and it is no longer an experiment, step 1 and 2 can be ignored on recent versions and the option to show the Shadow DOM can be found in the general inspector options.
To enable support and to inspect shadow DOM elements :
Enable the Shadow DOM and Developer Tools experiments in chrome://flags
Enable the Shadow DOM in the Inspector settings, this panel can be accessed by the cog on the bottom right of the inspector.
Check the 'show shadow DOM' checkbox.
Restart your browser
Elements which have shadow DOM elements will now be displayed in the elements tab:
This functionality now makes it possible to explore the different style options without having to take wild stabs in the dark or examine the webkit source code.