1. Don’t assume that SSD’s won’t/can’t fail.
2. When buying an SSD, check what controller it uses and then get on Google to see how many data recovery providers claim to support that controller; if you find one or less, buy something else.
3. Or even better, RAID and/or back up SSD’s just like you would HDD’s.
4. In the event of failure, an idle, unpowered SSD can retain its contents for a year or so at least with no degradation (YMMV/don’t test this on any data you care about!).
5. People will eventually figure out how to recover your data, if you give them enough money.
6. Making a filesystem dump of an old Windows install bootable again is probably easier now than it’s ever been.
7. Making an old Windows install (or installer) work with USB3.x and NVMe is nigh impossible.
8. With enough old hardware, several rounds of “musical SSD”, Windows 10 installation media, and sufficient masochism, it can be done.
9. Manually bootstrapping a GPT partition is also possible.
10. Not everyone is courteous enough to warn you when they suggest running commands that will immediately and irreversibly remove all partitions from a disk.
11. Windows no longer seems to care how many times you swap your install between completely different computers.
12. When USPS says “7-10 business days” what they really mean is “3-4 weeks, if you’re lucky”.

Anyhow, major props to ACE Data Recovery for figuring out how to restore data from dead Sandforce drives. And also to Recovery Force, for pointing me in their direction.

Normally scheduled programming of “mostly nothing much” should be resuming shortly.

What can I say that hasn’t been said already? So I’ll just encourage anyone who’s opposed to the idea of a Donald Trump presidency to join the millions that have already signed this petition:

• www.change.org/p/electoral-college-electors-electoral-college-make-hillary-clinton-president-on-december-19

It may have only a snowball’s chance in hell of actually accomplishing anything, but at least it lets you add your voice to the thunderous chorus of opposition. And not because Hillary won the popular vote. Or because Trump is a racist, a sexist, a self-confessed serial abuser of women, and an all-around abhorrent example of a human being. Those are valid issues, but they’re not what’s important here.

What’s important is that Donald Trump openly campaigned on a platform that falls somewhere in between tyranny and full-blown fascism, with campaign promises that have included (among other things):

• Jailing political opponents
• Removing legal protections for free speech and the free press, so that journalists can be sued, silenced, and suppressed
• Banning a religion
• Racial profiling and subjecting minorities to police search/frisking without probable cause
• Forcibly deporting millions of people, many of whom have been living peacefully in the U.S. for years
• Torturing suspected terrorists
• Murdering civilians (including women and children) when they have ties to suspected terrorists

And a government that tramples over peoples’ inalienable rights like that is exactly the sort of thing that the founding fathers sought to prevent.

The ideals of the founding fathers were freedom, tolerance, and equal rights and protection for all. Their single greatest fear was institutional tyranny. They established the electoral college as a guard against that possibility. Or, as James Madison put it in the Federalist Papers, to stop “a number of citizens whether amounting to a majority or minority of the whole, who are united and actuated by some common impulse of passion, or of interest, adverse to the rights of other citizens, or to the permanent and aggregate interests of the community” from taking over the government. Sounds a lot like what’s going on with Trump, doesn’t it?

It would be proper for the electoral college to block a Donald Trump presidency. Trump clearly and unequivocally promised to rule as a tyrant if he was elected. The policies he campaigned on and promised to deliver are “adverse to the rights of other citizens” and against the “permanent and aggregate interests of the community”. So yes, sign the petition and see what happens.

And in the meantime: denounce, rebuke and repudiate. Protest (peacefully!). Speak out against racism, intolerance, and baseless fears. Defend those least able to defend themselves. Oppose tyranny in all of its forms.

For anyone stumbling across this, I was employed as a senior-level Software Architect at iApps Pty Ltd from November 2010 to October 2013. By the time I left, I had climbed to ‘Chief Architect‘ status. And it’s time for the truth surrounding my departure from this company to be heard.

Let it be known that all of the information presented here is factual, and that I can prove every single statement made. Further let it be known that I am providing this information not with malicious intent, but to protect my own reputation and to clear up any inaccurate or incomplete tellings of this story that may have been circulated. If my reputation is to be tarnished, then let it be tarnished by nothing but truth.

And to my former employer, I say the following: Everything on this page is true, and you know it. If you genuinely feel otherwise, by all means feel free to skip the threatening letters and head straight to the courts to commence proceedings against me for defamation. But remember, it’s not defamation if it’s true. It’s not even defamation if it’s mostly true. Also remember that I’m still standing strong, unscathed, on the side of truth, transparency, and fairness. These are my principles; I will fight to defend them. All things considered, I think you’d be best off publicly acknowledging your past mistakes, expressing contrition for them, and taking your lumps. There’s a comments section below you may use for this purpose if you’re so inclined. But that’s entirely your decision.

The facts of the matter

This will be a bit dry and boring. As noted, I am simply stating the documented, provable facts of the situation; not providing a narrative. I invite you to color in your own narrative to go along with the facts as you read. Anyways:

1. On or around 22 November 2010 I commenced employment at iApps Pty Ltd as a senior-level IT professional.
2. The Professional Employees Award specifies the minimum terms of my employment with iApps Pty Ltd, although I was unaware of this at the time (having just migrated to Australia in September 2010, and not possessing any familiarity with the local employment laws).
3. The salary I was offered was substantially below the minimum wage for my position. Again I did not discover this until much later. At the time, I knew the offer was low, but not below-minimum-wage low.
4. I was told on multiple occasions, both before and after commencing employment with iApps Pty Ltd, that I would receive shareholding in the company. This enticement was a critical factor in my decision to accept iApps Pty Ltd’s offer of employment, and is commonplace when dealing with startup companies. Startups usually provide early or important employees with generous amounts of equity to compensate for the difference between an employee’s salary and their market rate.
5. No written document regarding my shareholding in iApps Pty Ltd was ever presented to me, nor were any specific details (allocation, vesting, cliff, etc.) ever clarified. Though I did ask for these things. Repeatedly.
6. Over the course of my employment, iApps Pty Ltd often expected myself and other employees to put in uncompensated overtime.
7. Although both the Professional Employees Award and the iApps employment contract required annual (or more frequent) reviews, no such reviews took place. One manager did attempt employee reviews, but her efforts were disregarded by higher-level management. This becomes relevant later on, around point #30.
8. On 4 October 2013 management issued a directive requiring all employees to take 12 annual leave days to cover a shutdown from 16/12/2013 to 3/1/2014 (inclusive); the directive required anyone with less than 12 days accrued to take the time as unpaid leave. For me, this was essentially the last straw.
9. I started researching Australian employment law and discovered that Fair Work guidelines don’t allow mandatory unpaid leave unless expressly permitted by an award contract. I notified iApps Pty Ltd, and the directive was modified.
10. I continued my research to determine what an “award contract” is, and finally discovered the Professional Employees Award and determined that it applied to me. I was shocked, and then appalled, to say the least.
11. From the Professional Employees Award I worked out that I had been underpaid since commencing my employment with iApps, and not by any small amount.
12. On 15 October 2013 I informed iApps management of the underpayment, and included a claim for repayment of the underpaid wages.
13. Also on the same day, I informed other similarly-classed employees of the Professional Employees Award so that they could check their own records. I requested that they temporarily refrain from submitting their own claims so that I could take the worst of the fallout from management. However, another employee had also been significantly underpaid and chose to submit his own claim.
14. On 16 October 2013, I was called into a meeting with iApps management. I requested the presence of the other employee who had submitted a claim. That request was denied, and I attended the meeting, in a small room, behind a closed door, with myself and three iApps managers. The other employee was eventually brought into the meeting, after a couple of hours.
15. iApps management professed a general unfamiliarity with the Professional Employees Award and Fair Work policies.
16. In relation to the above; the employment contract I signed in 2010 makes reference to “the Fair Work Act 2009″ and an “associated Modern Award”. It does not specifically identify the Professional Employees Award.
17. In relation to the above; the employment contract I signed in 2010 included a section titled “Schedule 2 – Fair Work Australia Information Statement”. The entire content of this section is “See attachment.”. I do not recall if any such attachment was provided to me.
18. In relation to the above; on 13 December 2012, a prospective employee sent to iApps management an e-mail that included the Professional Employees Award as an attachment, and a detailed discussion of its relevance. The initial offer from iApps to this employee included a salary component that was significantly below the minimum award rate. This prospect was hired and was paid the required wage.
19. iApps management attempted to convince me that I had violated company confidentiality policies by informing other employees of the Professional Employees Award (note that the award requires that copies of the award be made available to employees) and engaging in discussions about compensation.
20. Ultimately, both myself and the other employee were given the same ultimatum; we could 1) retract our claims, or 2) agree that we would accept equity in the company (the same equity that had already been promised to us by iApps, and still not delivered or even properly specified) in lieu of the wages claimed; and in either case continuing to work for below the legal minimum wage. If we did not agree to either of those options, management stated that they would immediately liquidate the company and that we would receive nothing. We were given until the next morning to decide.
21. I took the subsequent day off to seek legal advice, conduct further research, and evaluate my options. The other employee involved did the same.
22. I returned to the office on 18 October 2013, and was directed to attend another meeting with the same three iApps managers. I requested the presence of the other impacted employee, but the request was again denied. I was threatened with summary dismissal if I did not attend without him. I attended the meeting.
23. iApps management did not discuss the ultimatum that had been issued or ask if I accepted (though I would not have). Instead I was declared redundant on 18 October 2013 and asked to work out my notice period.
24. In relation to the above; while in the process of declaring me redundant iApps management stated that there was “no redundancy” for the skillset I possessed.
25. In relation to the above; on 16 October 2013 iApps management had also stated that there was “no redundancy” for myself or my skillset.
26. In relation to the above; iApps was actively advertising for candidates with a similar skillset at the time, and did continue advertising and performing interviews after my departure.
27. As part of my redundancy, I was asked to accept an offer to repay an unspecified amount of underpaid wages in small monthly installments. iApps claimed it would need “weeks” to determine the actual amount owed. I did not accept this offer, and we continued discussing terms.
28. In relation to the above; I had an HR professional review the facts surrounding my employment and compose a spreadsheet detailing the underpayments, the total amount underpaid, and how that amount was calculated. I provided this spreadsheet to iApps to speed the process along. iApps did not use it.
29. iApps management asserted that in seeking to recover the underpaid wages I was “cashing out” the shareholding that had been promised to me, and that I would therefore not receive any shares. I did not accept this assertion.
30. iApps management asserted that my position in the company was that of “Software Developer” and not “Chief Architect”. I did not accept this assertion, took it as a personal affront, and demanded an apology.
31. Although I continued working at iApps Pty Ltd for two weeks after alerting them of my underpayment, the wages I received on 25 October 2013 (and the entitlements paid out thereafter) showed that no adjustments had been made to raise my salary.
32. Due to the above issues and other assertions that caused me to believe that iApps was not negotiating in good faith, on 29 October 2013 I informed iApps that I found their latest offer unacceptable, that I considered their actions a fundamental breach of my employment contract and held the agreement “null and void” (though probably “repudiated and terminated” is the correct parlance), and that I would bring the matter before Fair Work Australia. I then walked out of that office, and never returned.
33. I proceeded shortly thereafter to initiate proceedings with the Fair Work Commission, citing the circumstances surrounding my redundancy, the manner in which iApps management had handled our dispute, multiple violations of the terms of the Professional Employees Award (minimum wage and uncompensated overtime, among others), and the nonexistent shareholding.
34. As part of the above proceedings, I expressed concern that two other iApps Pty Ltd employees (other than the employee who had also submitted his own claim) might also be underpaid. Both were eventually dismissed, one within hours of when I raised my concerns.
35. On 5 November 2013, I received a nice letter (page 1, page 2, page 3) from iApps Pty Ltd alleging some $200,000 in damages for claims that were primarily inaccurate or overstated. My response was essentially “Bring it”, but in far more words than that. iApps did not bring it.
36. We went before the Fair Work Commission:
     
    

    And we came to terms (Addendum 1: Covered Software). Terms that iApps Pty Ltd would ultimately breach.

37. iApps Pty Ltd failed to pay the final installment that was due on 30 November 2014.
38. On 4 December 2014 I advised iApps that I had not received payment (and received no reply).
39. On 5 December 2014, I again advised iApps that I had not received payment (and received no reply).
40. iApps Pty Ltd failed to remedy their non-payment within the 7 days allowed by our settlement terms.
41. On 11 December 2014 I notified iApps Pty Ltd that I acknowledged their repudiation of the deed of settlement, was executing my Common Law right to terminate the agreement, and holding any ongoing obligations that it may have placed upon me as at an end.
42. In relation to the above; on 11 December 2014 I did not refer to the previous attempts at providing notice. However, I shortly received a response from iApps management insisting that they had had e-mail problems and that this was the first message they had received from me on the subject, and chastising me for not calling them instead. I maintained my termination of the settlement.
43. In relation to the above; on 29 October 2013 I had advised iApps management that I would only communicate with them in writing, by e-mail. At no point did I retract or modify this.
44. In our subsequent discussions on the matter, iApps agreed to undertake repayment of the amount outstanding, owed as damages stemming from their repudiation of the settlement and its termination, and did submit payment.
45. I do not personally seek anything further from iApps Pty Ltd, other than perhaps a public acknowledgement of the above facts, an equally public apology for them, and a public retraction of any disparaging remarks made about me or my colleagues to my current employer or to anybody else in 2013 or at any time thereafter.
46. Australia has very awesome workplace laws, entitlements, and protections. And unfortunately it does need to have those things thanks to employers who think they can do the wrong thing and get away with it. That’s not a fact but my honest opinion, stated on a matter of public policy/interest. Workplace protections are important. The Fair Work Act 2009 and the various Award contracts are good things, and should never be undermined.

Response

Now, to respond to the allegations leveled against me in that letter (page 1, page 2, page 3) I received. I was held harmless for anything and everything alleged in there, but still. Let’s finish setting the record straight.

Yes, I did seek (and attain) employment with a former client of the company. This occurred after iApps delivered its ultimatum, making it abundantly clear that iApps either could not or would not honor the minimum terms of my employment contract. Why should I then show any further consideration towards an agreement that the other side was clearly unwilling or unable to uphold? Because they got me to sign a piece of paper using promises of a shareholding that was never delivered? Both of those questions are rhetorical.

Yes, I did walk out on the 29th of October, 2013. As clause 13.3 of the Professional Employees Award gives me every right to do when declared redundant. And which I likely was entitled to do regardless, as iApps wasn’t meeting the terms of my employment contract and had demonstrated a clear and persistent unwillingness to do so. The 29th is also my wedding anniversary, so now I have two things to celebrate on that day.

I did contact IBM/Avnet, but only to inform that them I was no longer employed at iApps and to request that they remove the association with iApps Pty Ltd from my personal profile in their system. If iApps’s reputation was damaged by the fact that I didn’t work there anymore…then maybe they shouldn’t have tried so hard to drive me away.

And I did erase my personal information from my workstation. Think things like Internet cookies/persistent logins, stored passwords to e-mail accounts and websites, chat logs, locally cached e-mails, browser history, and the like. All things that are of no value to my former employer, and all things that they have no business using before or after my departure. All of the actual work I did was checked in to SVN, and I did nothing to harm it. My conduct was professional, up until the very end.

However, I did leave behind a nice custom wallpaper, and configure the machine to play some awesome music at login. And to run a script that would set the playback volume to an enjoyable level while simultaneously disabling the system volume controls. It was all good clean fun, caused no harm to the computer, and would take any halfway experienced system admin no more than a couple of minutes to disable. I understand it caused a welcome distraction:

Anyways, back on topic.

No, I did not make “spurious” statements and allegations about iApps to damage their reputation or business. I said nothing untrue, and only discussed my situation in the context of seeking advice and evidence, protecting myself and my colleague(s) from the aggressive and intimidating tactics being used against us, and asserting my rights under Australian law. And besides, wanting to have a good reputation doesn’t mean you can do shady things and then assert that nobody can talk about them because they’re shady and will make you look bad. That’s absurd.

And $200,000 in damages? Fat chance. Though after three years on an iApps-level salary, that’s probably about how much income I missed out on while I was foolishly waiting around for them to make good on their promises of shareholding in the company. I ran my finances backwards waiting on iApps, and when I’d finally had as much as I could stand and demanded nothing more than what I had been promised and was legally entitled to, all they did was try to throw me under the bus.

Consequences

A number of things fall away as a natural consequence of iApps’s repudiation of our settlement and its subsequent termination by my choice (or to use the legal parlance, by my acceptance of their repudiation). Most important among these various things being terms clause 6, which shrouded all of the above events in secrecy, and terms clause 5, which was so broadly constructed that it made it nearly impossible for me to say anything at all about iApps Pty Ltd, ever.

The value of free speech and the right to free expression should never be discounted lightly. Free speech is important. Free speech is what keeps the tyrants in this world at bay. Without it, we are lost.

I miscalculated gravely when I signed away my right to speak freely. And it feels ever so good to have it back.

Acknowledgements

To those current and former iApps staff members who assisted me in gathering evidence and building my case, I thank you.

You helped me stand up to an adversary intent on ruining me, and an adversary who likely did their level best to bully and intimidate you as well; your support is appreciated and shall not be forgotten.

In closing

Now I don’t usually go for rap, but considering the circumstances I feel this is unavoidably obligatory. Set the volume on your speakers to ‘righteous’, and enjoy:

But allow even one parameter to drift too far out of line, and all you’re likely to end up with is a tangled mess of plastic:

Here are a few things that I’ve found can help at avoiding the tangled mess of plastic:

Glue – Use it sparingly, if at all

The Ultimaker manual recommends applying a thin layer of glue to the buildplate before starting a print. And yes, glue can help your print stick to the buildplate better, and it can be used to compensate for minor buildplate leveling issues that can’t be corrected in any other way.

The problem with glue is that it seems to accelerate the rate at which residue accumulates inside of the Ultimaker’s nozzle, leading to more frequent clogs and extrusion issues. It can also cause parts to stick too well, making removal a pain. In most cases, glue is completely unnecessary:

That part was printed directly onto the glass buildplate, and despite the very small contact area it stuck to the buildplate for the duration of the print. If you’ve leveled your buildplate properly, you should have no problems printing small and medium-sized parts directly on the glass.

For larger prints that make contact with large swaths of the buildplate, a small amount of glue can be useful in dealing with any minor adhesion issues that you encounter. I recommend printing the first few layers, then checking to see if there are any spots where the filament has come unstuck from the buildplate, and canceling the print, applying a small amount of glue just to the problem areas, and then restarting (or if you check and find no problem areas, just let the print run with no glue at all!).

If you see a large number of problem areas when starting a larger print, it’s better to relevel your buildplate than it is to try and solve the problem by covering the entire thing in glue.

Buildplate Leveling – The third screw

When leveling the buildplate, the wizard will point out the two front screws that you can turn to fine-tune your level. What it won’t tell you is that there’s actually a third screw you can adjust, as well. This screw is located underneath the build plate and towards the back (and in the center).

This screw adjusts the rear-center height, and can be very useful if you’ve just reassembled your printhead and now find that you can’t level things properly because one notch of height adjustment (through the printer’s wizard interface) moves from ‘a bit too low’ to ‘a bit too high’. By turning the third screw, you can dial in the middle ground between ‘a bit too low’ and ‘a bit too high’ and get your buildplate leveled correctly.

Oh, and since it’s not immediately obvious what affect adjusting the screws has, tightening a buildplate screw will lower the glass plate and increase the distance between the nozzle and the glass. Loosening will have the opposite effect.

Buildplate Leveling – The wizard only works once

The wizard that walks you through the buildplate leveling process is helpful; but only until your first successful leveling attempt. The problem is that the wizard will tell you to adjust the buildplate screws in order to level it out. But if you’ve already done this (and confirmed the result) then your buildplate is level and playing with the screws will only make it worse!

Once you’ve successfully leveled your buildplate the first time, it’s not going to drift out of level and the only thing you should ever need to adjust again is its offset height relative to the printhead. That’s the first and the fourth step in the leveling wizard and something you’ll want to do if/when you disassemble and reassemble your printhead, as the nozzle height is likely to change slightly when you do so.

So if your buildplate is already level, and you need to adjust the height using the leveling wizard, the only thing you want to worry about is step 1 (or step 4). The other steps you should just click through without touching anything. If you find you need to adjust the third screw in order to dial in the correct height, you should also adjust the other two screws by exactly the same amount to ensure that everything stays nice and level.

And in terms of getting to your first successful level, the wizard’s suggestion of using a piece of paper will get you pretty close. But the best way I’ve found to fine-tune things further is to start printing a large object and adjust the buildplate screws as the first layer is printing.

If you notice that the first layer seems too thin in some areas, then you’ll want to tighten the nearest buildplate screw to lower the glass a bit. And if you notice that parts of the first layer are too thick and/or not sticking to the buildplate, then you should loosen the nearest buildplate screw to raise the glass in that area.

The Nozzle – Clean it often

When printing residue can build up in the nozzle, resulting in underextrusion and clogs if left unchecked. And residue buildup can be difficult or impossible to actually see, as even if the nozzle itself seems clear there can still be enough residue stuck around the sides to cause problems with a print. This can complicate troubleshooting, as a number of other issues can cause the same sort of problems with a print making it all too easy to blame a different component for a problem that’s actually being caused by a dirty nozzle.

So it’s best to take a few minutes to clean out the nozzle every once in awhile. For instance, when changing filaments or whenever else you decide to remove the filament from the printer. The best way to clean the nozzle is to follow the steps described in the following PDF document:

https://www.ultimaker.com/spree/uploads/113/original/Ultimaker_2_Atomic_Method.pdf

Once you’ve gotten used to it, it should only take a few minutes to step through the cleaning process, and you’ll have ruled out a common but hard-to-spot cause of printing issues.

Hardware – The stock parts are good enough…

…good enough for printing better parts for your Ultimaker.

Seriously, there’s nothing wrong with the Ultimaker 2’s stock parts, but other people have been designing and sharing alternative versions that work better in most cases. For example, I’m currently using:

• Venkel’s fan mount
• IRobertI’s feeder system
• My own filament mount

With that setup, I get better prints, easier maintenance/troubleshooting, and more flexibility than what’s offered by the Ultimaker 2’s stock hardware. If you get a printer like the Ultimaker 2, one of the first things to do with it is print out some better replacement parts for it.

And whenever printing replacement parts out of plastic, always keep a second copy on hand in case the first one breaks, or has a run-in with the hot nozzle and melts, or whatever. Having a spare always available is worth the few hours that it takes to print.

Tuning – Extrusion rate isn’t everything

There’s a test print you can do to measure your printer’s extrusion rate. Despite much of the discussion surrounding the subject, however, there’s a lots more to getting a good print than optimizing the extrusion rate.

With the right parts, it’s actually fairly easy to get a successful extrusion-rate test. You can just dial down the tension on the feeder to the point where it will never skip backwards, and blow through perfect print after perfect print of the extrusion test. And then try to print an actual object that requires some retraction, and watch how fast your printer sands down the filament and jams.

What I’ve found is that better results can be achieved by tuning the printer to the speed you’ll actually be printing at. The extrusion test goes up to 10mm³/sec, but unless you’re printing very low-quality, high-speed parts then you’re not going to come close to that extrusion rate in practice. I personally never print above about 5-6mm³/sec, and find that I get the best results by increasing the feeder tension until the extrusion test fails around the 7-8mm³/sec mark.

That gives adequate extrusion for my prints, and also helps to ensure that the filament doesn’t just get sanded down to nothing on prints that make heavy use of retraction. It pays to work out what extrusion rate you actually need, and then tune your printer to that amount instead of just trying to tune for the highest possible extrusion rate. A successful 3d print requires more than just extruding plastic as fast as possible.

Printing – Use your ears

The Ultimaker 2 is a very quiet printer when everything is working well. And when it’s not working well, you can usually hear it.

The most common issue is underextrusion during a print, which can usually be heard in the form of loud and distinct ticking sounds from the feeder. An occasional tick isn’t usually a problem, but if you’re getting multiple loud ticks in a row it’s time to intervene if you want you print to succeed.

If you’re fortunate, the cause of the issue will be something simple, like a snag on your filament spool. Usually unspooling a bit of filament to get past the snag will solve this issue. If the ticking has gone on for awhile, however, you may find that you filament has been ground down/deformed a bit (especially if your feeder is tuned too aggressively).

If the deformation isn’t too severe, you may be able to clear the issue by gently pushing the filament through the feeder until the deformed bit is past the feeder wheel (and blowing/brushing off any filament dust that’s accumulated within the feeder). If you’re unable to do that, then you’ll likely have to cancel and restart the print.

In any case, if you’re attentive to the sounds your printer is making, you can generally catch underextrusion issues early enough to fix the problem and rescue the print.

Maintenance – User serviceable parts inside

The Ultimaker 2 is entirely open-source, and designed so that the end-user can repair, maintain, and modify it easily. Don’t be afraid to take it apart, modify it, and put it back together. As complicated as it can be to get all the variables lined up for a successful print, the machine itself is quite robust. You can’t really break it unless you try.

Which is good, because otherwise I’d probably have broken mine a few times over by now.

And yes, you can drag the printhead around to get better access at the parts on it. Just make sure you turn the printer off first! It will stay where you left it when you turn the printer back on.

Should all else fail, there’s also a very supportive user community that will help you sort out any issues you come across. Just pop in with a picture or two, and wait for the free advice to start rolling in.

So after several days of research I decided that I’d order an Ultimaker 2, straight from the Netherlands. I very nearly got a Form 1+ as I think that stereolithography is a vastly superior approach when compared to FDM. Ultimately, however, I was left with too many reasons stacked up against the Form 1+ (and of course, the frequent positive reviews of the Ultimaker didn’t hurt, either):

• Multiple reports from early users showing poor printer accuracy.
• Smaller build volume compared to the Ultimaker (and most other 3d printers).
• A time-consuming, messy, and smelly finishing process.
• Proprietary design with no/few user-serviceable parts inside.
• Very costly resin.
• Shipping logistics and costs with getting the printer to Australia.
• A slightly higher base cost.

That first point was actually a huge issue for me (what good is a 3d printer if it can’t print, accurately, in 3d?). I even contacted FormLabs Support to see if perhaps the Form 1+ had solved the accuracy issues and what their official calibration tolerances were when shipping a printer. Unfortunately all they could tell me was that the Form 1+ would be “more accurate” than the Form 1, and that they did not yet have any formally established tolerances as far as printer accuracy is concerned. That’s just not good enough. So an Ultimaker 2 is was.

The printer arrived last week, and I’m fairly impressed with it so far. It’s very easy to use, and comes with everything you need to get started.

After walking through the calibration wizard that runs the first time the printer is powered on, my test print came out with some minor issues:

As you can see, half of the print looked pretty good, but the other half looked kind of melty. After asking around a bit I determined that this happened due to the geometry of the Ultimaker’s printhead and cooling assembly. The printer comes with a single extruder installed, and with space already allocated for installing a second extruder as a future upgrade. The two extruder nozzles are positioned to be installed side-by-side, in line with the cooling assembly. What this means is that the Ultimaker 2’s cooling setup is actually asymmetrical, with one fan being significantly closer to the extruder nozzle than the other. This causes uneven cooling, and melty-looking results on the side that has the cooling fan further away from the nozzle.

This may sound like a fairly serious issue, but it’s actually an easy problem to solve. I was able to eliminate the asymmetrical cooling problem by printing out a custom cooling assembly (freely available; I used the ‘V06′ design found here) and replacing the stock assembly with it. My next print showed an immediate improvement:

So…the 3d printer can 3d print its own upgrades, fixes, and replacement parts. Soon we’ll have 3d printers spitting out improved versions of themselves, and all the companies selling these devices will be out of business. In any case, with the improved cooling assembly installed I’ve had success printing many things, from cups (watertight, but not dishwasher safe), to rubbish bins (a cup that’s accidentally scaled up too much makes a rubbish bin), to annoying cube puzzles, to custom-designed modifications for the drone:

In general it’s quite easy to print things. It’s pretty much just load up the part in Cura, transfer to SD card, and go. Cura is fairly easy to use, although some of the more advanced options could use a bit more documentation. My only major complaint about Cura is that in my opinion it’s overly aggressive about automatically retriggering expensive computations (toolpath and model updates) and brings my laptop to its knees as a result. However, Cura is open-source, and with a few hours of tinkering I was able to create a patched version that disables the expensive computations until the user says it’s okay.

In the end, the only real issue I see with the printer comes back to the cooling problem that I encountered on the initial print. If the printer is going to ship with a single extruder installed, then the cooling assembly that ships with it should be optimized for use with a single extruder. The dual-extruder shroud could easily be included as part of the upgrade kit for installing the second extruder. Taking it even further, however, what I really think what Ultimaker should do is redesign the printhead assembly by rotating the extruder nozzle locations 90 degrees from their current positions. That would put them in-line with each other but perpendicular to the fans, making them equidistant from the cooling source. It would also allow the same cooling assembly to be used with both single- and dual-extruder setups. Perhaps this is something they’ll consider for the Ultimaker 3. Or the Ultimaker 2+, if they follow the naming conventions that other companies seem to be using.

So overall the Ultimaker 2 is shaping up to be a very capable machine that’s simple and straightforward to use. I still think stereolithography is how we’ll end up printing things in the future, but the Ultimaker has shown me that there’s actually quite a bit that can be done with FDM.

Oh, and the accuracy? It’s spot on, on all axes. If I tell it to print a 1cmx1cmx1cm cube, that’s exactly what I get. Interlocking parts with relatively small (~1mm) features can be printed with ease. So no issues there.

Overall score: 9.0 / 10.0.

However some of them don’t or can’t, and unfortunately some will even deliberately feed bullshit information on the subject to their employees in order to avoid having to actually make good upon their promises of equity. So for the benefit of anyone who has unanswered questions on the subject of employee equity I am providing this article.

Be aware that I am not a lawyer, and do not claim to be. However I have worked with several startup companies and seen the employment contracts and equity agreements used by several others (startups and established firms alike), and invested a significant amount of my time in researching this subject. I think that makes me qualified to speak on it. I’m also not a liar, a bully, or a manipulator, and that ought to count for some measure of credibility as well. If that statement seems out of place to you, feel free to ignore it. Those who should know it to be true and relevant, will. And naturally you are free and encouraged to do your own research and to check the references I’ve used.

Anyhow, all equity agreements vary somewhat as far as the specific wording used. Some features, however, are essentially universal. These are the allocation, a vesting schedule, and a cliff. Many agreements will also include some verbiage around the subject of dilution, what happens if the company is purchased or goes public, and similar topics.

There will be more on all of those shortly, but first let’s discuss a couple of common misconceptions that are related to this subject.

Common Misconceptions
There are a number of myths about employee equity and compensation that you may find perpetuated at the less ethical startup companies. A couple of these are debunked here.

Equity is the “prize at the end of the race”. False. The value that the equity takes on over time is the prize at the end of the race. The equity itself is your incentive to run the race as hard as possible. Because that’s the only way your equity will ever have value. And it only works if you are allocated the equity before you start running. The fact of the matter is that you want to be allocated your equity when it is still worthless. If you wait for the company to become successful you’ll be stuck in one of two undesirable situations. Either 1) you will get hit with a massive tax bill when you finally do receive your equity that will probably force you to immediately sell off a significant chunk of it (which can be very difficult unless the company has gone public), or 2) you will be forced to take your equity in the form of options instead of as shares. Note that option #2 means that your equity will have zero value when you finally do get it (that’s the only legal way around the tax issue), unless your employer back-dates the grant date for you. And do note that back-dating options may be illegal. If your employer thinks you should run hard before they allocate you any equity, you should run all right; run away from your employer as fast as you can!

Market rate is lower at a startup. False. There’s only one market, and only one market rate. Regional fluctuations exist, naturally, but even those are diminishing as distributed teams, telecommuting, and similar practices become more widespread. In any event, a startup does not get a discount on the prevailing market rate simply for being a startup. Wages are virtually always lower at startups, because employees are allocated large chunks of equity to make up for the difference between market rate and what they are actually being paid. If a startup does not give this equity to its employees, then it has no excuse for offering any employee a below-market-rate salary. A correct reiteration of the original assertion would be “your cash wage is lower at a startup because you have been issued equity to account for the difference between your cash wage and your market rate”. If your employer says it any other way, that should be a red flag that something isn’t right. Doubly so if they say it in any other way in defense of not giving employees equity or of not paying employees the full market rate.

If you are unsure about the fair market rate for the job you perform, I encourage you to do some research on Glassdoor.com. For instance, here is the going rate for a technical architect in Australia. Here are some others:

• Creative director in Australia
• Graphic designer in Australia
• Project manager in Australia
• Human resources manager in Australia
• iOS developer in India

Glassdoor is full of useful information. But it’s time to move on with the rest of the article.

Allocation
With equity agreements, the allocation is simply the amount of equity that a person is being granted. This may be specified as a total number of shares (at an established/well-organized startup) or as a percentage of the company (at a fledgling/less organized startup which has not set up a pool of shares yet). Either approach is fine, although when shares are used you should be sure to ask your employer what the total size of the share pool is, since obviously receiving 10,000 shares out of a pool of 100,000 is quite different than receiving 10,000 shares out of a pool of 100,000,000.

The bottom line with any allocation is that you should be able to work out what portion of the business, as a percentage of the company, that you are being granted. This is useful for answering questions like ‘if the company is sold tomorrow for $1 billion, how much of that would I get?’ ($10 million per each percent allocated). There is no “standard” allocation, however your allocation should be appropriate to 1) your amount of experience/expertise, 2) the importance of your role to the company, 3) your market rate and the amount of salary sacrifice you take on, and 4) how early (or late) you joined the startup. Depending upon these factors, allocations may be anywhere from 1% to 20%, with exceptions made in exceptional cases.

When joining a startup company early in its life and/or at a significant salary sacrifice you should be reticent about accepting any offer that is below 1% of the company. Never sell yourself short; if you’re going to be working for a fraction of your normal/market rate you deserve to have full confidence that you will win big if/when the company is successful. Otherwise you are just wasting your time.

Vesting / Buyback
The allocation specifies how much of the company you get. However, you will virtually never receive your full allocation up front (and if you are offered such a deal and aren’t a founder/co-founder, it’s a sure sign that the company you’re working with is very inexperienced in these matters; you should do the right thing, and let them know that they really ought to be using a vesting schedule). The reason for this is simple. If the entire allocation is ‘paid’ immediately, an employee can join a company, resign the next day, and walk with their entire allocation. That’s very bad for business, for obvious reasons.

To solve this problem, you will typically receive incremental portions of your allocation over time. Should you leave the company (due to resignation or any other reason), provisions in your equity agreement will only permit you to retain those incremental portions that you received up to your final date of employment. That portion is referred to as the vested shares (or vested equity, if working off a percentage).

In essence, vested shares are the shares that the employee now owns, while unvested shares are shares which have been allocated to the employee but not actually handed over to them yet (the employee will get them eventually if they stay with the company, but doesn’t own them yet). Unvested shares gradually convert to vested shares based upon the vesting schedule. A vesting schedule will specify a timeframe over which vesting occurs, and at what increments unvested shares will convert to vested shares.

A typical vesting schedule will specify a timeframe of 4 years (this is basically industry-standard), with the allocation vesting in equal increments across that span of time. Increments are usually handled on a monthly or quarterly basis, although half-yearly and yearly increments are sometimes used. So for instance, if an employee is given 4% of the company and has a 4 year vesting schedule with quarterly increments, they will receive 1% of the company per year they remain employed, at a rate of 0.25% per quarter. Usually a vesting schedule will not prorate partial increments (i.e. if your last day of employment falls in between two increments, you will not usually receive vested shares for the partially completed increment).

Buyback is a feature unique to Australia (or at least, not seen in the U.S.; it’s possible other countries use similar provisions). In the U.S. a tax loophole exists (known as an s83(b) election) that allows the recipient(s) of equity to avoid owing tax on it incrementally as it vests. An equivalent loophole does not exist under Australian tax law, and so some companies will use a buyback provision to work around this fact for their employees.

Buyback works almost like an inverse of the standard vesting schedule. Instead of the allocation being held by the employer and then incrementally transferred to the employee as it vests, under a buyback arrangement the employee will receive the entire allocation up front and the employer will retain a right to buy back a portion of the allocation from the employee for some nominal (close to zero) value. This buyback right diminishes incrementally, such that at the end of the vesting term it has been reduced to zero and the employee now has full control over their shares. Separate provisions will generally prevent the employee from freely trading any shares that are still subject to buyback, typically by the employer retaining right of first refusal over any such shares, or other prohibitions on trading.

Recent changes to the tax code in Australia may have removed some or all of the taxation benefits associated with buyback provisions, so they may be less common now than in the past.

Cliff
The simplest possible vesting schedule will convert unvested shares to vested shares in equal increments across the entire vesting timeframe. Few businesses will use that approach, however, again due to the (entirely legitimate) desire to prevent people who stay with the company only a short while from walking away with chunks of equity. To mitigate that possibility, most startups will include a cliff in their equity agreements.

A cliff is essentially a modification of the vesting schedule to delay the vesting of some portion of shares until some timeframe has elapsed. For instance, a cliff may specify that no shares shall vest until an employee has been with the company for a total of six months, at which point any shares that would have normally vested during that timeframe (as specified in the vesting schedule) will vest all at once.

So if our employee from the previous example (who was granted a 4% allocation vested quarterly over 4 years) is also subject to a six month cliff and resigns after five months, they will not be able to take any equity with them. Similarly, if they instead resign after 7 months they will have satisfied the cliff, and be entitled to take their first two quarters’ worth of equity (0.5% of the company) with them.

Typical cliff durations range from six months to 2 years. Some startups may not use a cliff at all, and you should be wary of accepting any cliff that is more than a year or so in duration. Also note that a cliff may have tax implications (particularly when the cliff timeframe is longer than one year in duration), as it causes you to receive a larger block of equity all at once. When an equity agreement involves options rather than shares (i.e. when joining an established company instead of a startup), a cliff is not typically used as the allocation is generally much smaller and its real/immediate value is significantly less than when dealing directly with shares.

Dilution
Shares in a company don’t appear out of thin air. As new allocations are granted, the equity being allocated to the new employee needs to come from somewhere. This necessarily means taking some portion of equity away from at least one existing shareholder (or out of a preallocated pool, if one exists). When this happens, it is referred to as dilution.

Dilution is a relatively straightforward subject in and of itself, but failure to understand it can lead to disaster. For instance, let’s say that Alice and Bob are co-founders at a startup, and that Alice holds 80% of the equity and Bob holds the remaining 20%. If a new employee is allocated a 10% stake in the company, the following scenarios are possible; 1) all shares dilute equally, meaning that Alice’s holding will be reduced to 72% and Bob’s will reduce to 18%, 2) only Alice’s shares will dilute, meaning that she is left with 70% and Bob retains his entire 20%, or 3) only Bob’s shares will dilute, meaning that he is left with only 10% while Alice keeps her entire 80%. In all cases the new employee ends up with 10%, at least until the next employee comes along. Note that a 4th scenario is also possible, in which the company maintains a pool of unallocated shares to cover new hires coming on board; this effectively prevents dilution, at least until the pool is exhausted.

It should be apparent from those example scenarios that being the only person with dilutable shares is a bad idea. As The Social Network so entertainingly underscores, if you are the only person with dilutable shares you will quickly see your equity evaporate. Note that in scenario #3 Bob lost a full 50% of his original allocation due to a single new employee coming onboard. It would not take many more hires to reduce Bob’s shareholding to essentially nothing.

When dealing with an equity agreement that is specified in terms of shares (i.e. with an established/well-organized startup), the terms of the agreement should state whether the shares allocated are Common (which they will be 99% of the time), Preferred, or any other special type. Any special dilution rules that apply should be mentioned, although it is always wise to ask about how many different classes of shares the company has issued, and about whether or not any class of shares has preferential treatment with respect to dilution. In the vast majority of cases, all shares will simply dilute equally.

Conversely, if your equity agreement is specified in terms of a percentage of the company (i.e. with a new or disorganized startup) you should ensure that your percentage is specified as being non-dilutable until such time as proper shares are allocated. This provides incentive for the business to allocate actual shares swiftly, and protects you from any number of shady behind-the-scenes things that might be done when dealing with a dilutable percentage.

Generally speaking, it is fair and commonplace for everyone’s shares to dilute equally once shares have been allocated. Prior to that point, it is fair and commonplace for only the founders’ holdings to dilute up until the moment when actual shares are allocated. If your equity agreement is significantly different than this, think twice. And if it tries to make you the only person with dilutable equity, run.

Options vs. Shares
Depending upon where the company is at the time you join it, your equity agreement may deal either in options or shares (if your equity agreement deals in terms of a percentage of the company, expect your portion of the company to be delivered to you as shares). Shares are quite simple, and the norm when dealing with an early-stage startup. Each share has a value that is determined by the company’s net-worth/market cap, and the value of an allocation is simply the share value multiplied by the number of shares. Simple.

The problem with shares is that they have a real value at the time they are allocated, and this means that share allocations are taxable as income (though note that when a vesting schedule is used your shares will be taxable as they vest and not when they are allocated). This can cause some very significant issues. For instance one share of Google is currently worth a little better than $1,100. If Google were to give 500 shares to an employee, that employee would owe taxes on some $550,000+ in income, probably forcing them to sell 30-40% of their shares just to cover the tax bill.

The way around this tax issue is to use options. An option is not a share; instead it is the right to purchase a share at a set price at some time in the future. The price associated with an option is generally (unless the company has back-dated the option) the market price on the date the option is issued. This means that when options are granted they have zero real value, which solves the tax problem nicely and is why established companies use options in their equity agreements almost exclusively. It also means that unless back-dating is involved, options are completely worthless when you receive them.

To return to our previous example, Google could issue an employee options on 500 shares, granting them the right to purchase those 500 shares now or in the future for $1,100/share. The options have no immediate value (the employee can get 500 shares of Google, but only by paying $550,000 for them; the same as buying them on the open market). If the value of Google increases to, say $2,200/share, at that point the employee can buy 500 shares for $1,100/share, and then immediately turn around and sell them for $2,200/share, netting a $550,000 profit (which is taxable as capital gains). So options only attain value if the company’s share price continues to rise. If it remains the same or goes down, the options remain completely worthless.

If you’re joining a newly founded startup, you do not want to receive options unless the strike-price is fixed on or against your hire date (meaning that it is <= $0.01/share, since the startup should be close to worthless when you join). You should be offered shares in the company. If you are not then that's a good indication that you should seek other opportunities elsewhere. Words are Trivial
Now that’s all a fair bit to take in. And this is a good moment to underscore the importance of always getting a written equity agreement from your employer. Verbal agreements are notoriously unreliable and subject to differences in interpretation and perspective. Particularly when dealing with subjects like vesting and dilution that are extremely nuanced and virtually impossible to adequately capture in a verbal agreement.

If the startup company you are working with will not provide a written equity agreement, or fails to provide one in a timely fashion, that’s a strong indication that you should seek another employer. There is little reason for a startup company to not provide written equity agreements, unless the managers of the startup company simply do not intend to actually give anybody any equity (some people just don’t like to share; but thankfully their actions make them easy to spot). And you really don’t want to end up working at startups like that.

If your employer cannot tell you (in exact terms) your allocation, your vesting schedule, your current vesting status, or exactly what will happen in the event of an acquisition, resignation, or termination, they haven’t given you a real equity agreement!

Example Equity Agreements
For reference, I have included a some example equity agreements here. All are real agreements that have been used in practice, although any identifying information has been obliterated. Note that although some are far more verbose than others, all agreements cover essentially the same subjects.

The equity agreement that you get from your employer should be reasonably similar to these agreements. You should be able to easily pick out the allocation and the vesting schedule. If you cannot, be wary. Or if you have only a verbal equity agreement from your employer, be triply wary.

Thought Exercise
Now let’s consider a hypothetical example company, Transnational Application Production Services. At this company, employees are routinely offered salaries that are significantly below prevailing market rates. The typical “discount” is in the range of 50-75% off of market rate, which means that some employees are even asked to accept offers that are below the legal minimum wage. In exchange for this salary sacrifice, employees are offered equity in the company as part of their compensation. However, this offer of equity is only ever stated verbally, and although several employees request written equity agreements both before and after signing their employment contracts, no written equity agreements are ever provided by Transnational Application Production Services. Nor does the company provide any statements relating to vesting schedules, allocation size, or other issues typically covered in an equity agreement.

Can you guess what happens if/when an employee leaves the company? Do you think they will get to take any portion of the equity that was promised to them when they leave? If you answered ‘absolutely not‘, you are probably correct. In a normal startup company, every employee would have a document the specifies their cliff terms (if any), and what happens should they leave the company before or after the cliff period has elapsed. An Transnational Application Production Services employee has none of those things; and since their equity agreement relies upon a verbal contract, it would be very difficult for them to ever prove otherwise. A verbal contract is about as good as having no contract at all.

However, let’s say that we’re wrong, and that Transnational Application Production Services agrees to make good on its verbal promises of equity. Can you work out how much equity the employee will receive? If you answered ‘absolutely not‘ again, you are most definitely correct. Because the verbal agreement from Transnational Application Production Services never specified an allocation or a vesting schedule, there’s absolutely no way of knowing how much equity a given employee should or will receive, or how much equity they possess at any given point in time. Without a written agreement, everything is left up to the whim of Transnational Application Production Services.

Contrast that with a standard startup company, in which each employee’s contract specifies an allocation and vesting terms. This makes the task of determining how much equity a departing employee gets to take with them trivial, since it’s all there in black and white. By not having a written equity agreement, employees at Transnational Application Production Services are exposed to a significantly larger amount of risk than their counterparts at virtually any other startup. One hopes that the hypothetical management at Transnational Application Production Services would at least take the time to explain this extra risk to employees as part of their hiring talks. Though you may use your own imagination to decide whether or not that happens in our hypothetical world.

‘But surely there’s an upside‘, you say. And that’s a reasonable thought. Taking on increased risk is supposed to result in increased rewards, after all. But unfortunately no, that’s not how it works in this case. Because no allocation has been specified, each employee’s rewards have been left entirely up to the whim of Transnational Application Production Services and its management. There’s no minimum amount of equity that an employee at Transnational Application Production Services can count on getting. There’s no maximum amount either, but that’s not an added benefit because the same case exists at every other startup. Having an allocation specified does not preclude management from allocating additional equity to people it feels deserve it, it simply provides a minimum amount that every employee can be confident that they will get.

So employees at Transnational Application Production Services are taking on more risk than their counterparts at other startup companies. While at the same time they have less certainty about how much of a reward they will receive. There is no upside; the employee loses on both counts.

Things are quite a mess over at Transnational Application Production Services. Our hypothetical company is most definitely not a shining example of how real companies should be run. If Transnational Application Production Services reminds you of your own employer, you’d be wise to start seriously seeking out other options.

Of course, it’s entirely possible that the management at Transnational Application Production Services is simply uninformed about how to best handle equity allocations, as it is a startup company after all. It’s important to always give people the benefit of the doubt.

However, imagine that at our hypothetical company multiple employees have raised the issue of getting written equity agreements in place. And that some of them have even gone so far as to discuss the very issues covered above with their employer. And that our hypothetical company has made repeated promises with respect to getting together a written agreement but not delivered upon a single one. And that at Transnational Application Production Services the only person who has been given an actual allocation is a manager who takes home a six figure income while his colleagues work on below-minimum-wage salaries, while simultaneously and routinely asserting that everyone is being paid market rate and that there’s no money available for pay increases. And that those employees on below-minimum-wage salaries have repeatedly brought up the issue of their low rate of pay. And that the only employees to successfully petition for a legal wage were the ones who pointed out that their wage was in fact illegal. And that all of this has gone on for years with no corrections being made.

A certain pattern of inequity begins to emerge at our hypothetical company. Will this pattern of inequity exist at every startup company that doesn’t provide written equity agreements? No, probably not. But the lack of one should be a red flag that you may be working at Transnational Application Production Services. And that is not a company that you want to work for.

Ignorance is understandable, if deplorable (and also 100% correctable). Deliberately taking advantage of people, on the other hand, is just plain despicable. Companies which operate like our hypothetical Transnational Application Production Services are taking advantage of their employees and wasting everyone’s time. The company is getting work at a significantly discounted rate, and not providing anything whatsoever in return. ‘Thievery’ and ‘exploitation’ are words that come to mind.

Our hypothetical startup is about as bad as they come. We should all be grateful that such companies rarely exist in the real world.

This example further underscores the importance of always getting a written equity agreement that specifies your allocation, vesting schedule, and cliff whenever dealing with a real-world company.

Random Quote
No matter how you spend your life, your wit will defend you more often than a sword. Keep it sharp!

Disclaimer
All characters, companies and events in this blog–even those based on real people–are entirely fictional. All celebrity voices are impersonated…poorly. The preceding blog post contains useful information and due to its content should be read by most people. But not the elderly, people with heart conditions, or CEO’s of disreputable startup companies.

References

• Founders Workbench – U.S. s83(b) Elections (income tax loophole)
• Kevin Davis – Australia Buyback Tax Changes ca. 2012
• Skillshare Seminar – Employee Equity and Dilution
• From Little Things – Vesting, Equity, and Buyback in Australia
• Bond University – Options and Options Backdating
• Wikipedia – Equity Vesting in Startups
• Wikipedia – Stock Options
• Wikipedia – Options Backdating
• Personal Experience – Priceless

Previously if you wanted a free/open-source crash reporting framework for iOS your options were basically limited to QuincyKit, which is a serviceable but basic solution. Sadly, the backing architecture used by the QuincyKit server is not well designed and scales very poorly with the number of crash reports in the system. Once you have around 5,000 you’ll notice the server slowing down significantly, and go much beyond 10,000 that and the system grinds to an unusable halt. With a day or so of database and code refactoring, these scalability issues can be resolved, creating a system performant enough to track millions of error logs or more. But that’s a subject for another time. The point for today is that despite its basic level of functionality and flawed server architecture, there are a few key areas in which QuincyKit blows the default implementation of Jira Mobile Connect out of the water:

1. Automatic grouping of crash reports.
2. Automatic symbolication of error logs.

If you have any experience whatsoever with supporting multiple high-volume iOS applications you will instantly realize that these are features that you want. They might even be features that you want more than annotated screenshots, audio feedback, user chat, or seamless integration with Jira and all the awesomeness that Jira brings. In short, Jira Mobile Connect’s lack of support for these two key features may cause serious developers to pass it over in favor of other solutions.

Without grouping every single crash will be creating a new ticket in Jira that you need to track and resolve. Multiple instances of the same crash will have to be manually flagged as duplicates within Jira. And without symbolication trying to actually map back from an error log to the line of code that caused it is an exercise in futility, or at best, tedium.

In any case, rather than abandon the excellent potential shown by Jira Mobile Connect I decided that instead I would attempt to patch it up and add the missing features myself. It’s all open-source code, after-all, and if the tangled mess of PHP that is QuincyKit server can provide these features then they can’t be that difficult to implement. Unfortunately I had to change too many files in too many different places to show the code here, but if you want the short version of it I was able to implement both grouping and symbolication, and you’re welcome to view the complete diffs on bitbucket:

https://bitbucket.org/aroth_iapps/jiraconnect-ios-iapps/compare/..atlassian/jiraconnect-ios (client/native iOS code)
https://bitbucket.org/aroth_iapps/jiraconnect-jiraplugin-iapps/compare/..atlassian/jiraconnect-jiraplugin (server/Java code)

One interesting side-effect of adding groups was that it became possible for multiple client UID’s to be associated with a single Jira ticket. This had an important implication for feedback notifications/chat in that the reference implementation allowed only a single UID to be associated with each Jira ticket. Since the UID is used for determining what notifications/updates to send to the native client, this restricted update notifications to a single user per ticket. Not too useful if you have a common crash that thousands of users have experienced. The implementation above extends the data model to allow multiple UID’s to be stored against a single Jira ticket, allowing each UID to be updated when new feedback is posted by the developer on a ticket. In essence, implementing grouping also required the implementation of group feedback/chat.

There is one caveat with my server implementation, in that it assumes the existence of the ‘symbolicatecrash‘ utility on the system’s runtime PATH. This means that it will only work if your Jira server is hosted on a Mac, with the proper XCode developer tools installed (and with your application’s .app and .dSYM files copied to the local filesystem). This is of course a requirement regardless if you want automatic symbolication to work on any sort of system; somewhere there needs to be a Mac with ‘symbolicatecrash‘ available. In any case, it is a fairly simple matter to either turn this off or otherwise make it more intelligent, if your Jira server is incapable of running ‘symbolicatecrash‘.

Also note that the native iOS code has been restructured to build a universal iOS framework as opposed to an architecture-specific static library. This is done using Karl Stenerud’s excellent XCode4 Project Template. You will need to install this template in order to actually build the modified code. Or you can just refactor it back to build a static library again, but why would you want to do that?

When using the iOS framework, be aware that you will need to set the ‘-all_load‘ linker flag and also include all the images and nibs in the framework’s ‘/Resources‘ folder as part of your build. You will probably also want to include the ‘JMCLocalizable.strings‘ file in the same folder as well, to provide proper text and labels on Jira Mobile Connect’s UI elements.

Regardless, if you do a lot of iOS development and are already using Jira (like you should be) then I encourage you to check this out. This is the Jira Mobile Connect plugin, now with automatic grouping and error log symbolication.

Apple’s explanation (and seemingly, justification) for this atrocity of a feature is that “content should move in the same directions as your finger”. Now that’s all well and good, except for one thing; there is no “finger” when using a mouse. Touch- and mouse-driven are distinct input paradigms.

Apple is correct in that in a touch-driven system content should indeed track in the same direction as the user’s finger moves. If a hypothetical touch-based interface were ever released which scrolled content in the opposite direction of the user’s finger, then people would say that it was broken. And rightly so. Moving content in the same direction as the touch is the intuitive operating mode of a touch interface.

Similarly, moving content in the opposite direction of the scroll (or more accurately, moving the scrollbar in the direction of the scroll) is the intuitive operating mode for a mouse-driven interface. And it follows that Apple’s mouse-driven interface in Lion is just as broken as that hypothetical touch-driven interface would be. By Apple’s logic scrollbars themselves should also be inverted, tracking from the bottom of the scrollbar to the top as the content scrolls from top to bottom. Confused yet? Apple’s blunder here is that they have conflated mouse-driven input with touch-driven input, without bothering to translate properly between the two.

As an interesting aside, a comparable analog to touch-style scrolling does exist in the mouse-driven paradigm; the drag operation. You’ve probably seen it in things like Adobe PDF documents, and it can also be observed on any scrollbar. In the drag operation you choose an anchor-point, and then that anchor point moves in the same direction that you move, and it all intuitively makes sense. The problem with scrolling using a scroll-wheel is that it has no anchor point from the user’s point of view (they have done nothing to nominate one, and the UI does nothing to indicate that one has been chosen). In the mouse-driven paradigm, scrolling is a distinct operation from dragging, and by conflating the two Apple has broken their interface. At least until they start incorporating a touch-screen into every computer they sell.

If Apple’s position is to be taken seriously, then we must accept that the current cursor position must always represent where the user’s “finger” is. There’s one major problem with that, however. With a mouse and cursor, the cursor never leaves the screen. And if the user’s finger is in constant contact with the screen, then why should there be a separate scroll operation at all? It would logically follow (since mouse-driven == touch-driven and cursor == finger in Apple’s world) that since a touch-point exists, and since it is moving, the content (all of it, everywhere) should simply scroll whenever I move the mouse (all the time, everywhere). But of course that is nonsense, and so is Apple’s “natural scrolling” mouse behavior. The mouse cursor is not a finger, it does not represent a finger, and its location is not where your finger is touching. Mouse-driven and touch-driven are different modes of operation, with different intuitive behaviors.

Thankfully, you can turn off “natural” scrolling and rid your OS of its nonsense. I’ll be happy to turn it back on when my mouse is replaced with a touch-screen display, but until that day comes you can forget about it. Apple, please stop trying to convince me that moving my mouse cursor around the screen is supposed to be the same thing as dragging my finger all over a touch screen. It isn’t, and I’m not stupid enough to be convinced that it is.

Most importantly, the original architecture and caching hierarchy have been validated as capable of efficiently managing requests for a large number of comics pulled from several distinct data-sources, and the API verified as sufficient for creating complex comic-centric applications. Overall I am fairly pleased with the current state of the project, and thus I give you: