To remap my remote repo, I did this:

git remote set-url [example] [git://github.com/user/test.git]

where:

[example] = repo name

[git://github.com/user/test.git] = new repo url

Hi, I had two 9V/1W solar panels laying around at home and I was wondering what to do with them for a long time. Hopefully I’ve put them to good use finally! I also happened to have around some MC34063 DC/DC switching converters, wich I would like to use too, so this is basically what came out of them!

I bought my solar panels at mouser with a stock of components I needed for an old project, you can find them with this product code: 750-00031. They are made by parallax. The MC34063 are generic jellybean chips, as Dave Jones says (thanks a lot for the video too if you’ll ever read this, check all his videos and site, there’s a lot of great stuff over there), wich you can find everywhere, I’ve got mine in a SOIC-8 package at in an electronic components store in Mestre, but you can find them online for a few cents too.

Basically what I wanted to design was a DC/DC converter wich converts the power form the solar panels down to 5 volts  to use with any usb chargeable device you would like to charge/power, unluckily the power from the panels wouldn’t be enough to charge at a decent rate (let’s say 500mA) anything so I decided to use some AA NiMh batteries to store the charge and get the nice side effect that it works also with no sun at all.

What I came up with was basically this, much from the data sheet, I’ve just tweaked the values calculating them with the formulas also from the data sheet.
After calculating them by hand I’ve found out this nice page which contains a nice calculator ready for you to use..

Main schematics

I designed a board (which you can find at the bitbucket repository in the link at the end of the article) and toner transferred it to a copper clad board and etched with H2O2 + HCl in proportion of 2:1 as I found on this instructables.
It didn’t turn out too bad, I was a little worried for the little package of the DC/DC converter, but  turned out that wasn’t much of a problem at all.

I’ve built it up and tried it out, of course the first time I’ve soldered it upside down getting a nice short circuit -_- the nice thing is that it survived pretty well and after getting it correctly soldered up it worked like it was supposed to! I’ve measured out how it worked. I checked it with a simple NPN 2N222 transistor hooked up in a common emitter configuration with I controlled with a 20K potentiometer on the base and remaining down to 200/250mA  just not to blow it up. The ripple was under 100 mV  and it didn’t drop the voltage more than 50mV, so I was quite happy with it.

The battery pack I made provides 7,2 volts with 2300 mAh nominal current (Energizer). I know it’s not the best way to do it, you can do it better and with nicer materials, but that’s how I made it:

I used aluminum kitchen foil, a lot of black electrician tape and plastic to keep them tight together. I folded pieces of aluminum foil on themselves to create a thicker stripe with I cut and shaped like in the picture.

Battery connections

The bigger part it’s used to connect to the – terminal of the battery and the tape it’s used to insulate a bit one from the other
I put them in series like in the following picture.

battery pack

I placed the pieces of plastic over the contacts and taped it all up after trying it out ending up with this:

finished battery pack

After connecting the 2 “leads” to some wires scavenged form an old pc fan I proceeded to put 2 diodes in series with each solar panel and connecting them together to get to the input connector, connected the battery and measured some more with actual components instead of my bench suppl. I created an USB board to connect a cable to it and proceeded with some real life test under the sun!
I noticed that with full sun the system it’s working properly but when it’s darker it has some drop from the battery as long as they get emptier and close to their end life as I would expect.

Some pictures of the test.

Inner connections

Closed "box"

My android phone was happy with it and so was I!

ScreenShot

The trick to behave like a line adapter was to short out the 2 data line together, it will just say charging (USB) instead and draw 300 mA instead of a nice 500 mA like it’s doing this way. There is a strange way of charging an apple ipod touch/iphone/ipad/iwhatever using very big capacity batteries, as Ladyada found out here (check her site too, it’s really useful!).
I’ve made a board to set the 2 data lines voltage also to 2 volts just switching some jumpers if you need that.

I’ve learned quite a lot of things from this and there’s still much room for improvement, like getting an output status, monitoring the battery over-charge and a bunch of other things I’m working on, but for a first prototype I’m quite happy with it!
I’ve learned pretty much how to use the kicad EDA and learned some things about DC/DC switching regulators. I would like to add an AVR uC (Just because I’m used to them) to keep track of the output voltage and battery pack charge, maybe controlling a low power display or something like that.

If you want you can download everything I worked in from here: Bitbucket – solarPower there’s also a download for a little release with the schematics in pdf and the gerber board files.

I tried to use java at first but there was some problem with the photoset uploading wich was driving me mad..

After some searching I’ve found out that the tumblr team wrote an example in python to do just that (a bunch of person had the same problem apparently).
So, I learned python and went for it..
That’s what I came up with..

Bitbucket Repository – TumblrPicUploader

Have fun with that, read the readme file and if you have any question, just write me here or on my email.

Bye!

One of these days I will need commit to reading more T&Cs.

May the code be with you.

This week they announced support for BitBucket. BitBucket is a DVCS based on Mercurial instead of Git. (BitBucket does have a Git option when creating repositories.) So when the announcement was made I was pretty excited.

I use both GitHub and BitBucket. GH is perfect for my public projects and BB is perfect for my private projects.  It’s all about the cost.

Naturally I was excited when they mentioned the BB support. I thought… one tool, two repos.

But that is not the case. There is little or no documentation on this feature. The “manage repositories” is very unclear and the behavior seems to be adaptive. To what, I do not know. The one thing that is missing is a statement like:

While we have support for BitBucket, we are still limited to Git repositories.

That would make a lot more sense.  I’m not certain that I would convert my repos to Git because I happen to like mercurial better… and for no particular reason other than the fact that as a tool it is implemented in a single language unlike Git which uses several. This has the potential, and has in the past, failed to build when versioning goes bad.

Oh well, maybe later.

AppHarbor finally announces pricing for their awesome service. I’ll write up a post on this soon(ish), as it’s worth commenting on properly.

• Eclipse
• XAMPP
• Access to the shared BitBucket repo
• Mercurial
• WASCE

Setting up Eclipse:
I installed Eclipse a long time ago for a course that required using Eclipse.  I haven’t really used it since as I tend to prefer Netbeans.  I didn’t see it in All programs but I knew I had it installed so I did a quick search and found it.  The fact that Eclipse doesn’t appear in my Start Menu Programs list is just one more reason that I prefer Netbeans.  I hate making short cuts to things but I think I might add one to my desktop so that I don’t run into this issue again.

Although later I discovered that I had the wrong version of eclipse and had to go install Eclipse for Java EE.  Downloaded here.  Extracted all files to “C:\”. Ran eclipse.exe. Chose a workspace and it ran just fine.

Setting up XAMPP:
I’ve installed XAMPP before on OSX.  I downloaded XAMPP from here: http://www.apachefriends.org/en/xampp-windows.html#641.  When I ran the installer I made sure to set the destination folder to C:\xampp otherwise it won’t run.  I skipped installing Filezilla because I’ve got limited space and I only need the Apache and MySQL. I ran xampp_start.exe and then xampp_stop.exe (to stop xampp in the command line).  Then I opened xampp-control.exe and started MySQL and Apache running (click the start next to the name in the window).  I went into my Firefox browser and typed localhost/myphpadmin to bring up the My PHP admin box.  I have no clue what I did wrong along the way but it was in German.  So I fussed around and determined that “anzeige-einstellungen” is German for “Appearance Settings” and from there I recognized the language option and swapped it to English.  So I seem all set on this front.  I’ll need to come back and run the data base set up process but I’ll take care of that at a later date.

Setting up Mercurial with Bitbucket:
I followed the guide found here.

Setting up WASCE:
So I was trying to set this up and ran into an issue.  I began by downloading it from: http://www-01.ibm.com/software/webservers/appserv/community/. It asks for some information and then you can click download.  When I do it auto runs a download manager.  The download manager fails to be able to install the program and causes an error.  As such you have to go to where you downloaded the files and run the wasce_setup-3.0.0.0-win.exe.  Hit “Next” on the Introduction step then accept the license agreement and hit next again.  It asks to install to the default of C:\Program Files\IBM\WebSphere\AppServerCommunityEdition so you can just hit next again. Make sure you click “Yes, I would like to install the Eclipse Plugins” and that you pick the right folder for eclipse “C:\” Here’s where it got annoying.  I didn’t have the right copy of Eclipse (apparently there’s more than one) and I had to go get eclipse for Jave EE rather than just Java. So I held off on clicking next until I finished installing Eclipse for Java EE.  The next step is a review and confirm by clicking Install.  After it installs I let it pop open the First Steps window.

Here’s where I started following some tech notes provided by team member, David Wozniak.

{Start Tech Notes}
9) Have the install complete and launch eclipse
10) Go to the Java EE perspective
11) In the server view right click and select New -> Server.
12) In the option box select the WASCE v3.0 server under IBM
13) It will ask for the location of where the installer loaded the WAS CE. (C:\Program Files\IBM\WebSphere\AppServerCommunityEdition)
14) Click next and you will see an area to update the admin and localhost name. DO NOT CHANGE THIS NOW. If you do the server will not start.
15) Click finish.
16) The server should now appear. You can right click and select Start and Stop etc.
17) Now for the important feature:
With the server started. Right Click and Launch the Console.
All the configuration of the server will be from the web app that is launched. This is the same app that will run on the production server.

Log on to the console. Initially the user name is “system”, and the password is “manager”.

You can add more admins and remove the default login once you in. If you change it you will need to delete and recreate the workspace server updating the login information I told you not to touch in set 14.

{End Tech Notes}

At step 16 I encountered an error: “Starting ‘Newton’ encountered a problem.  Server Newton failed to Start.”  I did make sure that I didn’t change any of the information in step 14 by deleting and recreating the server.  It had no effect.  Here’s the stack trace:

!SESSION 2012-03-05 14:56:49.076 ———————————————–
eclipse.buildId=unknown
java.version=1.6.0_29
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US

!ENTRY org.eclipse.osgi 4 0 2012-03-05 14:56:49.082
!MESSAGE Error reading configuration: Unable to create lock manager.
!STACK 0
java.io.IOException: Unable to create lock manager.
at org.eclipse.osgi.storagemanager.StorageManager.open(StorageManager.java:699)
at org.eclipse.osgi.internal.baseadaptor.BaseStorage.initFileManager(BaseStorage.java:220)
at org.eclipse.osgi.internal.baseadaptor.BaseStorage.initialize(BaseStorage.java:154)
at org.eclipse.osgi.baseadaptor.BaseAdaptor.initializeStorage(BaseAdaptor.java:123)
at org.eclipse.osgi.framework.internal.core.Framework.initialize(Framework.java:190)
at org.eclipse.osgi.framework.internal.core.Framework.<init>(Framework.java:162)
at org.eclipse.osgi.framework.internal.core.EquinoxLauncher.internalInit(EquinoxLauncher.java:67)
at org.eclipse.osgi.framework.internal.core.EquinoxLauncher.init(EquinoxLauncher.java:37)
at org.eclipse.osgi.launch.Equinox.init(Equinox.java:178)
at org.apache.geronimo.main.FrameworkLauncher.launch(FrameworkLauncher.java:171)
at org.apache.geronimo.main.Bootstrapper.execute(Bootstrapper.java:49)
at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:65)
at org.apache.geronimo.cli.daemon.DaemonCLI.main(DaemonCLI.java:32)

I’ve googled around but I haven’t found an answer and I’ve run out of time to work on this at the moment.  A such I’m going to continue working at this at a later time.

Accomplished:

• Eclipse
• XAMPP
• WASCE (started)

To Do:

• Access to the shared BitBucket repo (waiting on invite)
• Mercurial
• WASCE (to finish)

Setting Up the Newton Environment – Take 2

One of my latest things is to take a library off Github (let’s not forget Bitbucket too!) and start playing with it. Recently, I needed a way of easily animating a background on a page and by chance stumbled across the Mishkin’s site: http://mishkins.co.uk/. Apart from ogling the food, the background transitions are amazing, even if you have low resolution images. I decided to peruse the source code to find they use a Jquery library called Supersized, a library which allows backgrounds to be loaded and displayed like a slideshow with lovely effects. It even handles stretching the image as you need and various other options.

Have a go. I love the way the web has progressed.

But the next plan up which gives you 10 people costs $10 a month which is a bit steep for someone like me. Also, 10 is probably still a bit low during a productive year.

Enter Bitbucket Academic License: unlimited private users, i.e., people you can work with, if you are an academic.

Sales pitch end

Mercurial was initially released about two weeks after Git, both with the goal of providing distributed version control for the development of the Linux kernel, but Git won that honor (not least because it was started by Linus Torvalds). On the other hand, Mercurial was conceived and began development in Minneapolis, so that makes it hip.

The scenario

I have some code to be released as open source when I get around to it, but I have plenty of code I just want in a private repository.

I have a Subversion (SVN) repository running off a local, free VisualSVN server. Great.

Kiln is built on top of Mercurial. Kiln is free for 2 users. I already use Kiln for some code. Great.

BitBucket is built on top of Mercurial and Git. You can create either type of repo. BitBucket is free for 5 users for private repos. BitBucket works with AppHarbor. I should use BitBucket if I want to use AppHarbor. Great.

Now to get to migrating.

A guide to a guide

First, an excellent guide to using the free, open source hgsubversion tool to migrate your SVN repo to Hg is available on the Atlassian blog, the relatively new owners of BitBucket. For all sorts of details I’m omitting, please refer to their blog post, as I am merely adding a few points here for what seemed like “gotcha” scenarios. My conversion was very basic, and the Atlassian blog post covers much more complicated requirements in greater detail. They also performed their conversion on Unix/Linux, where I was working from a Windows server, so you can get a feel for how the commands translate if you need to use the options I used on *nix.

Second, I couldn’t get the migration to work from a local SVN file source (file:///...), so instead of creating a mirror of the SVN server, I used the SVN server directly over HTTP. Because my SVN server was my local machine, this had no impact on the migration performance. Your scenario may be different.

Third, I simply used the “hg --insecure” option to get around the problem of self-signed SSL certificates, because I know my local server is only marginally a threat. If you need more options for dealing with SSL certs when connecting to your SVN or Hg servers, refer to the Mercurial manual/wiki.

Fourth, I simply cloned the hgsubversion repo and it worked for me. If you need to dive deeper, there is a great Mercurial kick-start guide on hgsubversion.

Installing Mercurial

If you’re a Kiln user, then I recommend you simply download the Kiln client installer, as it will include Mercurial, TortoiseHg for GUI activities, and their Kiln extensions for Mercurial. If you’re not using Kiln, then I recommend you install TortoiseHg, will will include the GUI and Mercurial itself.

Installing Subversion

If you plan to pull code directly from your SVN repo into your new Hg repo, then you don’t really need an SVN client installed. If your SVN repo runs on a remote server, then it would be best to mirror the SVN repo locally first.

If you don’t already have an SVN client installed, then I recommend TortoiseSVN, as it will include both GUI tools and the command line SVN programs.

Migrating Subversion to Mercurial

So, now it’s time to migrate the SVN repo to Mercurial. There is a free extension for Mercurial, called hgsubversion, that will perform the migration and preserve the revision history. Basically, you need to do the following:

1. Create a mirror of your SVN repo so you don’t accidentally screw the pooch during the migration. I skipped this step, but it may work for you.
2. Create a user map to convert the SVN author format to Hg format.
3. Create the Hg repo on the server.
4. Get the hgsubversion source code.
5. Create a clone of your Hg repo and dump your SVN repo into it.
6. Push the local Hg repo to the server.

1. Mirror the SVN repo (optional)

1. At a cmd prompt, where https://localhost/svn/main/Repo is the path to your SVN repo:
   

   md C:\hgsvn 
   cd C:\hgsvn 
   svnadmin create svnmirror 
   echo. > svnmirror/hooks/pre-revprop-change.bat 
   svnsync init "file:///%CD%\svnmirror" https://localhost/svn/main/Repo 
   svnsync sync "file:///%CD%\svnmirror"
   
   

2. Depending on the size of your repo, it might take some time to copy the repo's entire revision history into your mirror. Mine took a few minutes, but one of the projects at Atlassian took a few days.

2. Create a user map

1. Create an empty text file at C:\hgsvn\usermap.txt
2. Add SVN and Hg username mappings one per line, in the format:

   SVN Username=Hg Username
   
   

   So, you could have:

   Me=NewMe 
   Guy=NewGuy
   
   

   Or:

   Me=Me <me@me.com> 
   Gal=Gal <gal@gal.com>
   
   

3. Create the Hg server repo

1. Go forth and create the repo on your central Hg server, whether it be Kiln, BitBucket, or other. You will need the URL to the remote repo on the server to set it as the default host for your local repo. It can be used to set the default host when you clone the repo, but technically you can also set it at any time by editing the .hg/hgrc file in your local Hg repo, and setting:

   [paths]
   default = https://myusername@bitbucket.org/myusername/repo
   
   

4. Get hgsubversion

The hgsubversion project, like much of Mercurial, is written in Python, so Mercurial will run the extension as an interpreted script without the need for a precompiled binary.

1. Get the latest hgsubversion source. From a cmd prompt:

   cd C:\hgsvn 
   hg clone https://bitbucket.org/durin42/hgsubversion 
   
   

5. Clone the Hg repo and fill it with the SVN repo

1. I created a simple hgsvn.bat batch file, but you can also type the following at the cmd prompt.

   cd C:\hgsvn 
   svn ls https://localhost/svn/main/Repo 
   hg clone --insecure --config ui.username=myusername --config "extensions.hgsubversion=C:\hgsvn\hgsubversion\hgsubversion" --config hgsubversion.authormap=usermap.txt --config hgsubversion.defaulthost=https://myusername@bitbucket.org/myusername/repo svn+https://localhost/svn/main/Repo hgsvn
   
   

2. Wait a while, depending on the size of your repo, to copy the SVN repo in "C:\hgsvn\svnmirror" to your new Hg repo in "C:\hgsvn\hgsvn".

There are some important points crammed in those few options, so let's examine them more closely.

• svn ls https://localhost/svn/main/Repo

  This statement is there simply to form a connection to the SVN server, in order to cache your credentials if you need to authenticate to the SVN server. If your credentials are needed for authentication, you will be prompted to enter them after this statement. Your cached credentials will be needed by hgsubversion. If you aren't using localhost, use the name of your SVN server. If that is your local machine, it can be your hostname, but make sure it is in all lowercase.

  Theoretically, you can skip this step if you are using a local file path instead of SVN over HTTP.

• hg clone --insecure

  The "--insecure" option disables Mercurial's SSL certificate validation. If you're using an SVN server with a self-signed cert, this is required to connect to the SVN server, as unless you've established your local machine as a trusted Certificate Authority (CA), the server's cert isn't signed by a trusted CA.

• --config ui.username=myusername

  This is your Hg username that will be used for any commits to your local repo, or pushes to your remote repo. If you're using Kiln, your default username will be set to your Kiln username in the C:\%USERPROFILE%\Mercurial.ini config file, so you need to override it on the command line with your BitBucket or other username.

• --config "extensions.hgsubversion=C:\hgsvn\hgsubversion\hgsubversion"

  This enables the hgsubversion extension in the subfolder where you cloned the hgsubversion source. Note that the .py files are in an "...\hgsubversion\hgsubversion" subfolder.

• --config hgsubversion.authormap=usermap.txt
  This sets the usermap.txt file as the author map for hgsubversion. If you're executing the hg command from the same folder as the usermap.txt file, a relative path to the file will work fine.
• --config hgsubversion.defaulthost=https://myusername@bitbucket.org/myusername/repo

  This sets the location of your Hg server repo from which you are cloning your local repo. This will set the server address for use when it's time to push the repo to the server.

• svn+https://localhost/svn/main/Repo

  If you're using the local SVN mirror on disk instead of the SVN server over HTTP, use "file:///C:\hgsvn\svnmirror" instead. Otherwise, the points below are some of the most important.

  First, "svn+https" ensures that the resource is treated as an SVN server. Due to a conflict with Mercurial and Subversion support in hgsubversion, URLs starting with "http" are first treated as Hg servers. When the connection attempt is made, the authentication will fail, and the whole process will collapse. This is discussed at length in an hgsubversion issue.

  Second, "svn+https" uses SVN authentication over HTTPS and will use the credentials cached from the previous "svn ls" command. Without this, authentication to the SVN server will fail.

  Third, once again you can use "localhost" or a hostname for a local or remote server, but make sure that the hostname is in all lowercase. An uppercase letter in the hostname will cause the connection to fail.

6. Push the repo to the Hg server

Once the SVN repo is dumped into your local HG repo, you can push the commits to the server with "hg push" or the TortoiseHg Workbench.

I was a huge fan of Google Reader and its sharing capabilities. Generally the things I shared weren’t very thought provoking or worth posting to Google+ or facebook (which is clearly why Google ruined the sharing, they wanted to force people to share to Google+)… basically what I’m saying is that the things I tended to share were funny pictures I thought would make my friends smile. One thing I was never happy with was that I could only share to my friends who also had Google Reader, which made me turn to using Twitter to publish my items tagged with a “twitter” tag. This could have also been accomplished by allowing my shares to be public but I didn’t want them associated with my Google profile.

Once Google finally axed sharing I started to think of other ways to share out these silly pictures. I figured Tumblr was pretty much what I was looking for, just a stream of content. I didn’t want to have to sign in and create posts by hand every time so I thought that a cool way to automate it would be to create a Google Talk bot (since whenever I’m on a computer I’m pretty much signed into GTalk) that I could just paste image urls to and it would post them to Tumblr.

And so ChatBot was born! It’s an XMPP Bot which does exactly what I’ve described above.

I used tumblr-java written by Niall Sheridan to handle posting to Tumblr and SMACK to handle the XMPP side of things.

The source code is available on my bitbucket: ChatBot.

A build of it is available on my mediafire: http://www.mediafire.com/?xipvh04xccoc85c

If you want to try it for yourself all you need to do is download the zip file from mediafire and edit the config file.

Once you extract the zip file you will get the following directory layout…

• chatbot.jar is an executable jar file containing the project.
• lib contains all the 3rd party jars ChatBot depends on
• config contains the config.xml file used to store all the configuration information
• bin contains a .bat file which will launch ChatBot with the config.xml file stored in the config folder

To configure ChatBot simple edit config.xml under the config folder…

<config>
	<googleTalk>
		<userName>bot.email@gmail.com</userName>
		<password>MyPaZZw0Rd</password>
	</googleTalk>
	<users>
		<user>
			<userName>my.admin@gmail.com</userName>
			<displayName>Johnny Admin</displayName>
			<permissions isAdmin="true" />
		</user>
		<user>
			<userName>user@gmail.com</userName>
			<displayName>Jane User</displayName>
			<permissions>
				<activity id="ca.adrenalinaid.chatbot.tumblr.PostToTumblr">allow</activity>
			</permissions>
		</user>
	</users>
	<activities>
		<activity id="postToTumblr">
			<class>ca.adrenalinaid.chatbot.tumblr.PostToTumblr</class>
			<config>
				<userName>tumblr.email@gmail.com</userName>
				<password>myTumblrPassword</password>
				<subscriptions>
					<subscription>
						<subscriber>my.admin@gmail.com</subscriber>
						<postsFrom everyone="true" />
					</subscription>
					<subscription>
						<subscriber>user@gmail.com</subscriber>
						<postsFrom>
							<user>my.admin@gmail.com</user>
						</postsFrom>
					</subscription>
				</subscriptions>
			</config>
		</activity>
	</activities>
</config>

• Put your Google credentials under the googleTalk node.
• The users node is to configure the users that are going to be able to interact with the bot and to specify what they can do.
• Under the postToTumblr activity put your Tumblr credentials
• If you want the bot to notify specific users when posts are successful put that information under the subscriptions node.

Anyway, there it is! Feel free to send me any messages with bugs, questions, suggestions!
I’ll probably be moving on to a different project since this one is in a good enough state for now but I’ll definitely be coming back to this, add more activites, maybe make a UI.

Bitbucket è un sito di hosting per i sistemi di controllo versione distribuito DCVS Git e Mercurial. L’offerta di servizi comprende un issue tracker e wiki, così come l’integrazione con una serie di popolari servizi come Basecamp e Twitter.
Se siete interessati a capire in modo più approfondito servizi e possibilità che può darvi questo servizio vi consiglio di partire da qui.
Per utilizzare bitbucket, è necessario installare uno strumento DVCS sul computer in cui scrivete il codice dei vostri progetti. C’è la possibilità di usare bitbucket anche in altri scenari (non solo su Windows e per Visual Studio) ma questa breve guida tratterà di come gestire bitbucket in una macchina fisicamente vicino a voi come il vostro computer di casa o lavoro. Ecco quindi gli step da seguire.
Per prima cosa iscrivetevi a bitbucket.

Installare Mercurial e VisualHG
TortoiseHg 2.2.2 è la versione attuale per Microsoft Windows di Mercurial. Scaricate l’installer a questo indirizzo e installate il programma. Successivamente scaricate e installate VisualHG che è il plugin di Mercurial per Microsoft Visual Studio.

Utilizzare Mercurial in Visual Studio
Aprite Visual Studio, andate sul menù Tools sulla voce Options. Scorrete la lista fino a trovare Source Control e selezionate VisualHG. Sull’area online che vi mette a disposizione bitbucket create un nuovo repository e copiate l’URL. Create una cartella sul File System per dove metterete il codice, selezionate le proprietà della cartella e troverete la voce TortoiseHg. Premete su clone e vi apparirà la schermata che segue.

Impostate come source l’URL che avete precedentemente copiato e premete Clone. A questo punto vi verrà chiesto di inserire utente e password, confermate e inizierà la procedura.
Aprite Visual Studio, aprite il vostro progetto e se tutto è stato configurato correttamente avrete uno scenario di questo tipo (tratto dalla documentazione di VisualHG)

Per maggiori info potete andare a consultare la documentazione di bitbucket e quella di TortoiseHg.

But enough of the boring stuff.  I decided last semester that I love computer programming, and even more so, that I want to put the time in to be good at it.  Not, not good.  Great.  So over break, I spent a fair amount of time reading up in the Stanford CS Library as well as various programming blogs like Joel on Software, Steve Yegge’s Rants, and Coding Horror, and my reading prompted me to make the following New Year’s Resolutions:

1. I will use version control.  Not just for CS assignments, but for papers as well.  As both Joel Spolsky (Fog Creek, Stack Overflow) and the guys at Reliscore described, the use of version control is one of the things that sets apart the good programmers from the great ones.  I can’t tell you how many times I made copies of my project folder for my Yale Daily News iPhone app — I realized that I needed to do version control, but at that point, hadn’t bothered to learn to use git (or even XCode’s built in repository system, for that matter).  But now, I am convinced.  So after a fair amount of research, I installed git on my computer, and set up an account with BitBucket to handle my online repositories.  Why BitBucket, you ask, rather than Github or Google Project Hosting?  Simple answer: free, unlimited repositories (public and private), and, if you’re a student, unlimited users.  BitBucket also allows you to keep Mercurial repositories, which is nice if you prefer that to git.  Also, for Mac users, SourceTree, made by the company who runs BitBucket, is a brilliant GUI for Git and Mercurial on Mac OSX.  Although I will make an effort to learn how to use git from the command line, SourceTree will really help to keep myself organized.
2. I will learn how to use and write test scripts for my assignments.  In a technical interview I had the other day, I was asked not only how to optimize an algorithm for a given problem, but also what test cases I would implement to check that algorithm.  I was able to come up with a few on the spot — EOF conditions, whitespace, non-ASCII characters, int overflow errors, null pointers — but developing test cases on a regular basis will challenge me to think in a more complete way about the problems that I am solving.  I also decided that I will write my test scripts in Python, which, quite obviously, will help me learn Python.
3. I will learn as much Linux as possible.  There are so many ways in which Linux can help with coding, whether they be command-line utilities like grep and sed or software like emacs (yes, I know I can use it on a Mac, but I much prefer TextWrangler) and valgrind.  If I want to consider myself a real programmer, then Linux is a must.

Those are my resolutions.  I’ll let you know how they go!

Last few weeks

There’s been a couple of things on my mind for the last few weeks that have been holding up my posting.

• Still reading Raymond Chen. My next Blog’s I’ve Read entry was going to be The Old New Thing blog from Raymond Chen. With a post every day from him for the last 9 years, I started at the beginning of 343 odd pages with 10 posts a page and have only about 60 left. The quality of the content I’ve found there makes me want to make that the next post for the category, but I want to get up to date first in case something exciting happens.
• I’ve been considering the best way to post my updated version of Very Sleepy. After writing about my changes, I wanted to publish a version that people could use to see if it fixes their issues and if they like the more responsive interface. My first idea was to speak to Yuriy O’Donnell and piggy-back on his Sleepy-ex project on bitbucket.org. Thinking further (and after having spoken to Yuriy) I realized that it would be better to look into creating my own project for sharing. With Git and Mercurial both being something outside of my comfort zone, using a DVCS is something that I’ve only read about in depth without having actually used it yet. It feels a bit overkill to use a DVCS just to share some code and an exe.
• My HTML5 work has stalled based on a loss of motivation. My work-in-progress game has been in-progress for the last few months. I’ve got to several points where I’ve had something showable as simple example of using some of the HTML5 features I depended on, but I wanted to take it to the point where I could show off a basic game. Of course, by saying game, I need to make sure I include all of the auxiliary bits that you expect with games, such as menus, score, timer etc. I’ve always been a big fan of the “find the fun” philosophy when creating games, but looking at my bodged together interface makes me want to add some more polish before testing it some more and looking for the fun.
• Finding time to work on my JavaScript code. Actually getting to the code to write some more is the biggest challenge since dropbox isn’t the kind of thing you can install on a corporate network for giggles.
• Wanting to update the blog. While travelling during the Christmas break, I left the laptop at home but still wanted to keep working on some posts. As this list of random things is proof, there’s been several ideas I’ve wanted to post about, but not in much depth. The problem is, when I have an idea, I want to note it somewhere. I did look at WordPress for iOS as a possibility, but then I was too busy to try it.
• Mentally tossing up the value of Twitter. Again, with these random ideas I want to post about, I was thinking I could squeeze it down to 140 characters and dip my toe in the water. However, I realised that once I got started, most of my tweets would be either retweets of other’s work or me expressing anger at SouthEastern trains, delayed ferries and other tidbits that would interest few if any.
• And then my iPhone broke. I managed to get a bent pin in the connector port. First problem, I only discovered this when I got home and wanted to charge it since the battery was nearly dead – the pin was stopping it from charging. Second problem, I hadn’t backed up since the iOS 5 update which was about 6 weeks out of date, and the phone wouldn’t talk to iTunes. I spoke to one of the Apple Geniuses at the Genius Bar and he suggested a wifi sync when I got home, hoping that I could get enough copied off in however long 17% of battery lasts. However, before I left work, one of my colleagues was able to apply finesse and fine copper wire to bend the pin back up so that a cable could be attached. That got me to 100% battery and leaving the cable in until I got home meant that I could connect to iTunes and backup. (For reference, wifi sync appears to need to be enabled in iTunes with the phone connected so would not have worked ) The next day I went back and paid for an out of warranty replacement phone, fortunately 1/4 of the price of a new one and installed it straight from the previous night’s backup.
• Investigating SkyDrive. During a cloud discussion, we had a who’s got the biggest free storage contest and SkyDrive won with 25GB for starters whipping my iCloud‘s 5GB (personally I think that the iCloud storage should scale on the size of device and accumulate for multiple devices). I’ve been looking at how easy it is to get things in and out with something like SDExplorer and soon will go crazy by putting all my photos on there.

The rest of the year

Looking forward to the rest of the year, there’s several things I want to post about:

• The first thing is a status update for my HTML5 stuff (or rather publishing that post-in-progress with a link to the work-in-progress). I’d then like to polish off what I was working on and write something more in-depth. WebGL is still sitting in the back of my mind, but I just can’t use it on the iPad yet.
• A review of the games I enjoyed in 2011 – it’s been a great year for PS3 and I’ve played some really enjoyable games.
• Looking at some upcoming games or writing about my experiences. I’m already looking forward to SSX and Borderlands 2 this year. Now if I could just finish off the other games in the queue.
• More blogs for the Blogs I’ve Read category.
• Maybe an iPhone app or two that I’ve enjoyed.

I am extremely happy with my Networking Essentials results. :D Pretty sad with my Database Fundamentals mark, but I hope that’s not an indicator of how well I design databases when I go out to the real world. I did great in my database subjects back in TAFE….

Anyway, back to writing up this Git and BitBucket tutorial that’s hosted here. It’s not even half-finished and yet it’s a wall of text already. But I’ve learnt a lot in regard to VCS’s and some of the differences between distributed VCS’s and centralised VCS’s, and those damn line endings. I really hope Windows 8 follows Mac OS X and stick to LF when it comes to EOL marking.

EDIT: Something went wrong, apparently, with the posting of my Database Fundamentals mark. It is now 78, giving me a Distinction. W00t! ]]> http://ecoders.wordpress.com/2011/12/12/how-to-delete-a-remote-git-branch/ Mon, 12 Dec 2011 15:09:36 +0000 emilpk http://ecoders.wordpress.com/2011/12/12/how-to-delete-a-remote-git-branch/ Today I needed to delete one of my remote branches.  Here is the solution I found, simply run this command from GIT Bash:

$ git push origin :remoteBranchName

So if for example your remote branch is called “testBranch” and the remote is called “origin”, you would run:

$ git push origin :testBranch

Hope this helps anyone out there.

https://bitbucket.org/malb/algebraic_attacks/src/1af75effcc7d/coldboot

For this code to run you’ll need to apply this patch to Sage:

http://trac.sagemath.org/sage_trac/ticket/10879

which adds an interface to SCIP. Unfortunately, this patch crashes on OSX and I didn’t figure out yet why. Anybody willing to help, please step forward

Also, I assume the code on bitbucket needs some patching to work with the most recent version of Sage. Patches very welcome!

• Why Version Control
  • Choosing a VCS for research materials
  • Setting Up A Bitbucket Repo
    • Installing Mercurial
    • Setting Up a BitBucket Repo
    • You Need A Local Copy
  • The Workflow
  • Mercurial Resources
  • Other version-control-like options

Why Version Control

In the long, long ago days of March 2010, Julie Meloni posted a piece on the ProfHacker blog on version control systems (VCS) and what they might offer to the everyday academic trying to hack her workflow. If you don’t know what version control is, take a look at that post. VCSs originated with the specific needs of software programmers to save, access, restore, share, collaborate asynchronously on code. Version control has become a cornerstone of software development, and even more so of the social aspects that mark open source/free software communities. Sites such as Github have flourished because of the ease with which individuals can share, fork, and otherwise review and distribute code for open source projects super small and super large. (That’s right– the linux kernel.) There are a number of open source VCSs that are available free of charge, including Subversion (svn), Git, and Mercurial (hg).

That’s all well and good for code, but what does it have to do with an historian’s research repository? Well, the basics of version control boil down to this this –> documents placed under revision control are tracked by the VCS. Changes to those documents are committed, together with a message summarizing the changes, to a repository. Repositories can be replicated, or cloned, on any machine that has the VCS installed. In essence, every change to a document that you save and commit to the repository is eternally there, and can be returned to. Differences between versions of documents can be visualized. There are other useful aspects for academics as well– including branching, which allows you to create a parallel version of any document and develop it independently. Just as an example, say you have a single CV that you want to adapt for specific venues (grant applications, job applications to different types of universities/colleges, etc.)– with varying degrees of ease depending on the VCS, you could branch that CV into different forms tagged by their intended use. With a few simple commands, these changes can then be synced across your computers.

Suffice to say, a VCS offers an academic the ability to maintained versioned backups of his or her research and other personal files. And, for my own DIY predilections, I must admit that I like repurposing tools intended for wholly different audiences and putting them to work for historical research.

Choosing a VCS for research materials

Following Meloni’s advice back in March of 2010, I began to play with svn for maintaining a repo of my research and writing. (This post, for example, will be committed to my svn repo, which I haven’t yet migrated away from completely.) My webhost offers svn repos as part of its standard hosting package, and so I went that direction first. I was attracted by the idea in part because as a commuter, I have a variety of personal and work machines that I use on a regular basis — and I wanted all of my research files to sync on all those different computers. I also am attracted to the idea of redundancy in backup methods. I currently have offsite backups of my main laptop on backblaze. I have some of my stuff in Dropbox. I also clone the hard drive of my laptop once a week to an external drive. Paranoid, I know. But I’ve come by that paranoia honestly.

When I started in earnest to collect, transcribe, and analyze sources for my next project, I decided I wanted a project-specific, version-controlled repository for my sources and python scripts related to the project. I could have done this with my svn repo on my server. With svn, a single central repo tracks folders and files. You checkout either all or part of the repo, work locally, and then commit everything back to that central repo. Works great, though svn makes some things like branching overly difficult.

After putting a small bit of code up on Github, I discovered that I liked working with git, which operates on a different model than svn. Git clones repositories to wherever you want them in their entirety. Changes to documents are made to a local working copy of the document, committed locally, and then pushed/pulled to/from other repositories. Branching is much easier, as is merging changes back in. But, these are my research files, many of which aren’t ready for prime time yet. Github offers private repositories, but only for pay. I’m a cheapskate historian, so I went looking for a service that offered even a limited number of private repos for free. Enter Bitbucket, which offers free public and private repos for accounts with up to five users. In fact, BitBucket also offers an unlimited license to academics with a verifiable .edu address. I like companies that offer educator discounts. Given the availability of free private repos, I decided to go with Bitbucket for my research archive.

Setting Up A Bitbucket Repo

Bitbucket now supports git, but when I started this project, it didn’t. So, the rest of this post will be a tutorial on using Mercurial with Bitbucket. As long as you’re not scared of using the command line a little (and would you be reading this if you were?), basic usage is very straight forward.

Installing Mercurial

The most important first step is to install Mercurial on your machine. There are a couple of options for doing this. The easiest is to download the appropriate package installer for your operating system (OS X or Windows) just as you would any other piece of software. On Linux, install with your distribution’s package installer.

Alternatively on a Mac, if you use homebrew you can install with:
$ brew install mercurial

Finally, if you’re familiar with python and use either easy_install or pip, you can install that way. Mercurial is written in python, and is available as a python package. So, for a systemwide install, you simply need:
$ sudo easy_install mercurial
or
$ sudo pip install mercurial

Mercurial uses hg (the chemical symbol for mercury) as its alias on the command line. So, to verify that the installation worked, open a terminal prompt at enter:
$ hg --version

As of this writing, you should see something like:
Mercurial Distributed SCM (version 2.0)
(see http://mercurial.selenic.com for more information)
Copyright (C) 2005-2011 Matt Mackall and others

This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Setting Up a BitBucket Repo

Once hg is installed, the next step is to set up the private repository for your research materials on Bitbucket. It’s a painless process. Fill out the information on the sign up page. Please note that your username will define the urls for your repositories, so choose it carefully. If you may want an educator’s unlimited account in the future, provide your university email address.

Once your account is set up, log in to your account. From the Repositories tab, click on create repository. One the next form, create a new repository from scratch by providing a name (like, say, “Research”). Make sure that Private is selected, along with Mercurial as the repository type. You can also choose to use either an issue tracker or wiki for Project Management. This is actually a cool feature. For humanities projects, I like to use a wiki, which I then use for project planning, large project ideas, and the like. Click on Create repository, and voila, you have an empty repository. Navigate on over to your new repository page, which will be in this pattern: https://bitbucket.org/<username>/<repo&#62;. Nothing to see there yet, but now we’ll fix that.

You Need A Local Copy

OK, so now we need to set up a repo on your local machine to work with your bitbucket repo. We need to make a folder for the repo, we need to clone it, and then we can start to populate it with research materials that we’ll push back to bitbucket. This is the same process you’ll follow on any other computers you’d like to have your materials on as well. So, here we go.

First up, make a folder to put your repo in. I like to use a projects folder in my home directory. YMMV. Time to get a little used to the terminal, so let’s do it there. From your home directory, which is the directory Terminal will probably open in (if not you can always get there with a simple $ cd), enter this command at the prompt:

1. $ mkdir projects

The road to version control forks here. When cloning your remote repo, you have two options. The first, using https requires you to enter your bitbucket password each time. The second uses ssh and requires that you enter an ssh key once in your bitbucket account settings. Let’s look at the latter. On a Mac, this is pretty easy. We need to change into a hidden folder. You should already be in your home directory, and if you are, enter this:

1. $ cd .ssh
2. $ ssh-keygen

This will create an ssh public/private key pair. Open the public key with vim or nano or your favorite text editor. It will most likely be named id_rsa.pub. You can check with $ ls. Highlight the entire key and copy it to your clipboard. Now, go back to your bitbucket account page and paste the key in the Add Key box. Now, back to your terminal. Change into your projects directory and clone the repo:

1. $ hg clone ssh://hg@bitbucket.org/<username>/<repo>

Of course, substitute your username and repo name there. This will create a new folder with the name of your repo, and where your files will reside. The https method is similar, but requires no keygen, so you would have gone straight to cloning the repo for step two:

1. hg clone https://<username>@bitbucket.org/<username>/<repo&#62;

That said, I prefer the ssh method.

Either way, you’re ready to go!

The Workflow

Now that your repos are set up and linked, we can start putting files in them. Mercurial tracks files, and not folders. So empty folders won’t show up. Also, binary files (like, for example, .docx files) are more difficult than plain text files for VCSs to track. Mercurial will detect changes to a .doc file, but will store a whole copy of the new version rather than just the changes to the file like it does with txt. This can cause, over time, the repo to get large. But, as I’ve argued here before, plain text files are more durable, platform independent, and compact. I’ve switched to taking all my notes in .txt files, using markdown/multimarkdown syntax. I’ve also started switching excel spreadsheets to .csv files wherever I can. OK, back to the workflow.

On the most basic level, working with Mercurial will involve the following steps: 1. adding new files to version control; 2. committing changes in those files to the respository; 3. pushing changes from the local repo to bitbucket.

On a day-to-day basis, the workflow looks like this. If I’m transcribing a new document, I save that file to one of the folders in my local repo. The folder structure is normal– however you like to set up your research files. At some point, I add the new document to version control with the command: $ hg add. This will add any file in the repo to version control that isn’t already. As I accumulate substantial work on a version controlled file, I commit it to the local repo with $ hg commit -m "A message about the work." Note that hg requires a commit message with any commit. I find the log of messages a nice way to track my progress. At least once a day (depending on how much work I’ve gotten done), I push the local repo changes to bitbucket with $ hg push. I do this almost entirely using D-Term, which rules and provides a dropdown command line already in the directory you’re working from. And, that’s it for the most basic workflow. I now have an iterative back-up of all my research files both on my local machine at in the private repo at bitbucket. There are more advanced commands that are useful as well, but I’ll save those for another time.

A couple of final caveats — putting a file in the trash doesn’t remove it from your version control history. The proper way to erase a file is with the command $ hg remove <filename>. Likewise, the proper way to rename a file is with $ hg rename <filename>. Otherwise, a file will show up as missing, and will need to be removed at the next commit. You can also get into trouble with conflicting versions in different repos, which require merging.

If you’re not comfortable with the command line, there are a couple of nice, and free, GUIs for managing an hg repo. For the Mac, there’s the aptly named MacHg. For Windows, there’s TortoiseHg.

Mercurial Resources

There is, obviously, much more to Mercurial than I’ve listed above. In the future, I’ll cover branching and merging scenarios for typical humanities work. Luckily, in the mean time there is some excellent documentation available. Brian O’Sullivan has a free online version of his **Mercurial: The Definitive Guide. There’s a nice tutorial by Joel Spolsky. And Bitbucket’s support pages are also useful.

Other version-control-like options

If you’re not ready to make the plunge into a full-fledged VCS, there are other options likely already at your finger tips. That’s certainly the case if you use a Mac. With the release of OS X Lion, Apple has integrated version control more explicitly into its operating system. If you look at the save dialogue from the File tab on any program, you’ll see that Save now says Save Version. This form of save is actually tracking changes, and earlier versions can be browsed if the application supports the feature. Together with Apple’s TimeMachine, that takes you a pretty long way towards version control of your documents. Additionally, for Mac users, programs like ForeverSave offer version control for pretty much any program and their binary files. If you use DropBox, you can pay a little bit extra to turn on version control that can be accessed from their web interface for anything you keep in your DropBox.

Dropbox isn’t platform specific, but I must admit that I don’t know what the ForeverSave or OS-Specific options are on Windows or Linux. Feel free to share such in the comments.