Colours Hackathon

Last week we had our first Hackathon at Colours, and it was a blast! There were a lot of great ideas, ranging from better time-tracking apps and a mobile poker app for Scrum poker sessions, to multiple content management add-ons and even an iBeacon utility that you can easily administer online. My submission came in at a third place (just behind the poker app and a standardized Drupal website with generation wizard) and, of course, was related to Sitecore. I worked out my concept of bringing component statistics (analytics data) directly to the content editor, showing the relevant data per component in the Page Editor.

My idea basically came down to the following two questions: How often does a content editor really take action to change his content based on website statistics (most of the time only visible to the web analyst)? And wouldn’t it be great to get this information per component?

After a fun night of coding, Laphroaig Cask Strength whisky (oh that’s sooo good), lots of table soccer games of questionable quality, loud and good dubstep (but also some traditional Belarusian music from our Minsk-colleagues), pizza, fries and Red Bull, my concept started coming together. I started with a clean Sitecore installation of version 7.5, built a small website to demonstrate my concept (some renderings do work with live content, but not all of them) and then I’ve built the data collection events. Lastly, HighCharts was used to display the results.

You can get a more in-depth view of my concept and implementation by watching the following screencast:

which is also available via YouTube directly: Hackathon entry – Page Editor Statistics in Sitecore.

Of course, this is just a concept and there are a lot of additional things to figure out, like:

  • The (for the demo removed) speed measurements should be re-entered and extended with the load time in the browser, not only the load time of the DOM structure (this was only built to demonstrate the concept).
  • The page load registration should be moved to an asynchronous call, as is the case with the ‘scrolled into view’ demo.
  • It should be made possible to follow multiple components that use the same layout on one page.
  • The fly-out should be made dynamic (only fly in on hover for example) and tested within the Page Editor extensively.
  • Storing the statistics in xDB would be way better than storing the data on the item itself, mostly in regard of scalability and performance.
  • Personalization should be implemented to get more accurate statistics and to be useful within personalized websites.

So keep in mind that it’s just a demo of a concept, built during a hackathon while having fun (and a little sleep) too. But you’re more than welcome to comment on my video on YouTube or to extend my concept, but please share it with me, as I shared the concept with you and intend on making it an Open Source Sitecore plug-in that may be ready to appear on the Sitecore MarketPlace one day :-).

Left wing structure

In the past two weeks I spent a few evenings to finish up the wing structure of the left wing. Despite the complexity of the wing structure, it goes together quickly and almost effortless. You can see I’ve added a bottom main spar, leading edges, multiple aft spars (flaps, ailerons and inner spar), the outer wing tip structure and multiple servo hatch supports. By the way, I changed the way the ailerons are controlled: the plans suggest one central aileron servo with push rods and bell cranks, but this hard to adjust later on and also prone to result in a sloppy control mechanism, causing flutter far more easily than with a short rod and a direct connection between servo and control. So I added two servo hatch supports where the aileron servo will go and dropped the whole push rod and bell crank construction. A lot easier to build too. Here’s the wing structure almost finished:

And from another angle:

Then I cut out some rib material and placed the retract rails to test fit the retracts and struts. It looks like it fits in very well but there’s a problem:

As you can see in the following photo, there’s not enough clearance for the wheels, which are 3-1/2″ high and 1″ thick:

I tried to play with the tracking of the wheels and rotated the strut upward a bit, but I still cannot get enough room under the strut for the wheels to fit in. I find it strange, because these struts look a lot like the ones suggested in the manual – they even say you might be able to fit a 3-3/4″ wheel in there… – but long story short, this isn’t going to fit.

The original full scale struts have an offset, where the center of the wheel is aligned with the center of the strut. I initially bought these straight struts because they look like what the manual suggests, they are called ‘P-47 Struts’ and they fit the retracts I chose, being from the same manufacturer. Now I think I should look out for offset struts, because they give me more play and as a bonus, they resemble the full scale struts a lot better. So I returned the straight struts and ordered Offset RoboStruts instead (thanks Aerobertics.be for the great service!)…

Although I cannot continue with the current building step of installing the retract rails, I may be able to do some more things further down the list, like skinning the control surfaces and installing the shear webs. To be continued!

Starting with the wings

I had to wait for the retracts to arrive before I could start with the wings. Luckily this didn’t take long and last week I received my order. It’s a set of 85-degrees 60-120 sized retracts with a pair of matching oleo struts from E-flite. E-flite calls them P-47 struts, probably because they fit their Hangar 9 Jug, but they do not resemble the real ones all that much.. which isn’t a problem for my semi-scale build, even more because they look very nice and of course, a lot better than wire struts:

Before starting building up the wing structure, next to some general prep work, I had to modify a number of parts to fit these specific retracts. Most modifications are mentioned in the build instructions, but I had to pick only some of them and I also needed to modify the rib cutout for the retract mechanism, as I use servoless retracts that didn’t exist when these plans were drawn:

Once that was done, the structure of the left wing arose very quickly on the building board:

Nice to see how all those ribs line up, floating above the plans due to the building tabs:

I would have liked building both wings simultaneously, but I do not have enough room for that, so I have to build them one at a time, but I think this could go very fast from here nonetheless.

Finished the fuselage

Last week I finally got the time to finish up the fuselage!

I’ve mounted the firewall and the motor mount. Went together very well. Because of the right and down thrust angles, you cannot just center the motor mount on the firewall and my mounting points did not match those of the plans. So I aligned the motor mount using CAD drawings I’ve made. Seemed like a daunting task, but it wasn’t:

Then I recessed the rudder for the elevator joiner wire. Not mentioned in the instructions or on the plans, but a very obvious step needed to make the rudder and elevator fit together:

So I finally could test fit and assemble the tail and check the controls throws of the elevator. Looking good:

Then I buit and installed the fuselage antenna, just behind the cockpit, from 1/8″ birch ply. It’s remarkable what such a small detail does to the overall appearance of the plane:

… installed the servo tray:

And finished the battery hatch! This was a small little puzzle on its own, but I managed to get everything sorted and I’m very pleased with the result. First I’ve installed a canopy latch on the front side of the hatch:

Then, I glued some wooden dowels into the other side of the hatch:

After drilling the corresponding holes in the fuse itself, the hatch fits snugly into the fuselage opening and there’s absolutely no play at all. A nice and clean installation:

And last but not least: the pin of the canopy latch is in the right location to represent the front antenna on the fuse of the Jug! So it’s scale too :-)

By the way, I’m not sure if I can do the checkered pattern on the cowl, but if so the Snafu absolutely is my first choice to replicate visually.

Motor mount

After cutting a prototype by hand I’ve changed the design of the motor mount slightly. The sides are cut out differently to save some weight and I’ve removed the cooling holes in the front for more strength. Also, the offset turned out to be too large and was reduced from 80 to 74.5 mm. Then I found that hand cutting didn’t deliver the results I’d hoped for and the plywood from the DIY-store wasn’t good enough (too much voids and hard to get clean cuts). So I decided to order my parts laser cut, which was easy because the design was made in CAD in the first place. I’ve added the motor brand and type engraved in the front, not only because it looks cool, but mostly because the front plates are the only parts where it’s difficult to tell which side is up.

Yesterday I received the parts cut by Laserbeest, only one day after placing my order! Looks good doesn’t it?

Because my design is interlocking, it doesn’t need glue to stay together in the direction of the pull of the prop, which lessens the change of ripping off the motor on a sudden throttle increase when a glue joints fails. All parts only fit in one way too, to make it fool proof to assemble. The exact offset for this application and the added one degree downthrust (I know this motor has way more torque than the adviced two- or four stroke engine as designed by Top Flite) make it a breeze to install. I hope the tapered design adds to supporting the relatively heavy and large motor.

Here’s a dry fit of all parts, which went together like a dream:

I really enjoyed the process of designing my own parts, maybe I’ll design a complete airframe in the (near) future… this tastes like more! Now find some time to assemble and install this mount and continue building the Jug :-).

Content delivery with Sitecore

Just a quick blog post to share my latests findings on the content delivery topic. I recently presented this mechanism at one of the SUGNL meetings and received positive feedback from fellow developers, so I thought it would be nice to get into detail some more with this blog post. When you are not using solutions like TDS, keeping track of all content that was changed by developers and needs to be deployed with your code changes as well, can be an error-prone and challenging task. After looking at all possible solutions, I hooked up multiple free (and Open Source) utilities to automate this process. It turned out to be rather easy to setup and we do have a lot of benefit from it in our development and deployment process.

In the past, we all used the same central Sitecore database located in our company network. This lead to conflicts once in a while, if you were making breaking changes. Also, all developers had to be connected to the company’s network via VPN at all times. For this new technique, we switched to working with local databases only. Each developer machine (laptop in our case) becomes a stand alone development environment with their own database, IIS instance and Git repository. Now we can develop disconnected, share versions in content changes as well and are more flexible in our branching strategy!

How does it work?
We embedded Unicorn into our solutions, a tool that serializes all content changes to disk. Accordingly, these content changes are committed into our Git repositories along with the code changes they accompany. Upon pulling a new version of another branch, we deserialize this content back into our local database (synchronization process) to get the database state that corresponds to the code of that specific version. That is very cool, because now we can not only retrieve each others database states when working on different feature branches without getting conflicts, but we also can browse through history, checking out old branches and getting the database state that was active back then. This is very useful while debugging and using the Git bisect functionality.

So we can exchange content changes, but how do we deploy the latest changes to our test, acceptance or production environments? Well, to know what has changed, we need to make a diff. And to make this delta, we need an old and a new version of the serialized data. So I’ve created a very simple Git command that copies the complete serialized data folder to another folder called ‘initial’, that stores our initial state of our release branch, before starting the merge.

#!/bin/sh

echo "removing old initial copy"
mkdir -p Data/initial
cd Data/initial
rm -f -r *
cd ../..

echo "creating new initial copy"
xcopy Data/serialization/* Data/initial /E

echo "ready for merging feature branches"

After that we start merging in our feature branches that need to be deployed. This will also merge in serialized changes into the Data/serialization folder, creating the updated version that is a merge of all feature branches that we are going to deploy. And now comes the magic: using Sitecore Courier we can very easily generate a diff package based on those two folders. I included this into an admin page within our solution, which can be loaded by TeamCity automatically. Courier creates an Update package (not the regular Sitecore package with a .zip-extension) that is recognizable by the .update-extension. Update packages can also update only one field within an item and they can delete content too, something that’s not possible with the regular Sitecore packaging functionality.

Installing these Update packages is very easily done via the /sitecore/admin/UpdateInstallationWizard.aspx page, but because I didn’t want any manual intervention I added one last utility to the mechanism: Sitecore Ship. This utility allows us to automatically install an Update package with TeamCity.

So now we’re all good to go! We don’t need to keep track of our changes (only be careful what to commit, no test content please!) and everything is deployed automatically. Both content and code. And we can even browse through history and switch to each others database states of different feature branches. I think it’s a cool alternative to TDS, it’s fully Open Source, you can extend it in any way you want and it only takes about one day to setup and configure.

What are the pitfalls?
Of course, there are a few things to take into account. If you include all Sitecore content, including media items that are stored in the database, your serialization folder will grow beyond sizes that are manageable with most version control systems. And you cannot merge blob data either. So I decided to exclude media items from this mechanism. If you ever need to deploy media items as a part of your development changes, you will need to do this manually. But for the rest, I absolutely did not have any performance issues with a serialization folder containing over 46,000 files and being close to 200 MB in size.

The other drawback is the need to synchronize whenever you pull new changes or check out another branch. This takes a few minutes for large solutions and sometimes a conflict in your serialization files will appear. But in general, it works very well and those few minutes waiting are well worth the ‘effort’, looking at what you get back from it.

Maiden flight

As mentioned in my previous post, the maiden flight of the Christen was great! It tracks like it flies on rails and it didn’t need a single click of trim! Also, the CG seemed to be spot on right away with the batteries all the way back on the tray. Had a slightly bumpy landing on the first try, but I couldn’t be happier with how this maiden went! I have a few pictures of the maiden flight I’d like to share, thanks to my fellow club mate Frans.

Waiting in the pit, ready for takeoff:

Coming out of a looping:

Some more in-flight shots:

It has a beautiful presence in the air:

Bringing her back in:

And a happy post-maiden photo to conclude this build:

I really could recommend Hangar 9, as the plane was easy to build with only some minor issues, but more importantly it flies superb. Having advised control throws and expo settings in both low and high rates is an amazing help too. Of course, you could fine tune anything to your liking, but it’s reassuring to have a well flying basic setup to start with. Also, in retrospect, having chosen for an electric setup paid off as well, as it’s easy to install, start and fly. But it turned out to be very powerful too. So it’s clean, simple and with this size of motor and prop it doesn’t even sound bad either.

Looks like I have a new favorite plane in my hangar!

A successful maiden!

Just a quick post to tell it flies superb! Today the Christen Eagle flew its maiden and it’s so smooth, docile and powerful at the same time! The plane tracks beautifully and is easier to fly than I thought. Only flew in low rate though. I did four flights today and already got to some basic aerobatics like loops, rolls, Hammerheads and a half Cuban Eight. The Power 90 really is sufficient, you can fly just over half throttle and on full throttle it seems to climb forever. Great for very large loops and Hammerheads. The only challenge is landing… the Eagle comes in very well and steady like a rock, but you should be aware of the Multiple Landing Syndrome. My first landing was good for a first, but ended up bouncy nonetheless. Second one was spot on, third had a small bounce as well and the fourth was okay.

I will post some pictures of the maiden once I’ll receive them from a club mate.

Flight preparation

Yesterday I’ve checked the CG once again and it still seems to be just fine with the batteries all the way back on the tray. On the given center of gravity, the plane seems to point its nose very slightly downwards, but I’d rather see this than leaning to tail heavy and they’ve given a range that should be okay around the marked CG of almost 1/4″ either way. I’ve also used all standard / adviced components, so all in all this should be it.

I saved the following step in the building process for last, because I wanted to know where the batteries had to go for the correct center of gravity. Now I know where to place them, so I could install the hook and loop tape on both batteries and tray, to prevent the batteries from sliding back and forth. I also had to enlarge the recesses on the front side of the tray, because the batteries were too short to make it up to the stock recesses. With my latest additions and adjustments, the batteries can be strapped in safely and very tight:

And finally, I got to setting up the control throws, dual rates and expo. I set up the high and low rate control throws per manual, together with the expo settings mentioned on the website of Hangar 9. I defined one switch for all surfaces, so I can toggle between the two modes with the flick of a switch:

I’m planning to take off on low rates, especially because of the sensitivity of the tail wheel / rudder. If this is not enough, I can always switch to high rates, but as I’ve read in multiple reviews, the plane should fly relatively calm and easy on the low rate settings, which is a good thing for a maiden flight. I really hope to fly the plane on Saturday.

I’ll keep you posted!

Finished!

After a little tweaking and fine tuning the hole in the spinner back plate, I got it nearly perfect. The plane doesn’t vibrate anymore up to at least 75% throttle. On full throttle, there’s some slight vibration, but nothing serious. I might need to balance the spinner cone as well though.

But first, I wanted to finish the last steps of the build. One thing that was bothering me, was a bad solder joint in the battery harness for series packs I bought. I didn’t feel I could thrust these joints and after a little fiddling my suspicions were confirmed:

So I ordered a few more parts and made myself a new one with solder joints I could rely on. It’s also a little larger, so I could more easily reach the connectors when installing the batteries:

And then, I only had to install the wings and connect the ailerons of the bottom and upper wing panels. Per instructions I needed to slide them in, secure them with three machine screws (each bottom wing has one and the upper wings are connected with a screw too) and connect the servo cables of the ailerons to the receiver. But I was in for an unpleasant surprise. When screwing in one of the machine screws, which has to go in a pre-installed blind nut, the screw got stuck a little. I was sure I got it perpendicular to the surface in both directions so I continued with some more force applied. Then, it got stuck completely and the blind nut came loose, starting to turn with the screw.. this is bad. I couldn’t see or reach the blind nut, as it was pre-installed in a now hidden spot. I couldn’t reach it with pliers or so and there was no way the screw wanted to loosen up.

I tried a lot of things to get it out. I had to. The screw wasn’t fastened completely, but my wing was on… so this way I couldn’t transport the plane and I couldn’t fly it… I tried to drill the screw out, but the drill bit hardly made a dent in the hardened steel of the machine screw. The only solution I saw to literally save my plane was to cut the head off of the screw using a grinding disk and my Dremel tool.

The grinding made a mess inside my fuselage, but eventually, the head came off and the blind nut fell out. But I couldn’t prevent the washer from getting launched when I hit it with the grinding disk… it became so hot, it fell right through the covering on the bottom of the fuselage!

When the blind nut was out, the cause of all this became very clear. When installing the blind nut in the factory, the little barbs on the blind nut just folded inwards. This caused it to start turning, but this also made the blind nut going in in an angle, which was the reason my machine screw started binding in the first place.

I couldn’t use the blind nut anymore, since the thread was stripped, so I temporarily installed the wing using a regular machine screw and a butterfly nut. I then fixed the hole in the fuselage with an all white decal cut to size. You can imagine I wasn’t too happy with this crappy blind nut installation job.

After having tackled this issue, everything went smooth again. The wings are on and I’ve assemblded the push rods inbetween the ailerons. And that was the last step of the building process in the manual. So today, only 18 days after I started ‘building’, I have finished my Christen Eagle II!

The CG was rather accurate straight away, but I will check again tomorrow and use some hook and loop tape to fix the batteries in the right place. The last thing left after that is checking and programming all control throws and maybe dialing in some expo.