You read more about it from the GitHub project page

 
The first number represents the number of seconds 1/1/1970. The second number represents the time offset from UTC (presumably from the location where the date was created).  I’ve seen a whole lot of confusion on the internet about what to do with the second number on deserialization. Many people try to adjust the time they got from the first number with the second number. Do not do this. The reason the second part exists is ridiculous and relates to a change Microsoft made to .NET between version 1.0 and 2.0.

When Microsoft released .NET 2.0, they introduced a new property DateTime.Kind which affects the behaviour of the ToUniversalTime and ToLocalTime methods. If you have a DateTime representing a kind of “Local” then converting ToUniversalTime would return a DateTime with a different value however if the kind of the DateTime was already Utc then calling ToUniversalTime would return a DateTime with the same value. Presumably the Kind property could be queried by UI controls in order to determine whether conversion is necessary before display.  I would argue that internally you should always store DateTime as UTC and then always convert to Local (or whatever timezone you need) on display. There is a highly questionable performance advantage to internally storing dates as local time.

The only information you need to reconstruct a valid time is the first number. The Microsoft JSON deserializer will ignore the + or – as well as the second number and only uses their presence to indicate the DateTime.Kind of the deserialized DateTime structure. This Kind will only affect whether the internal value of the DateTime is stored relative to 1/1/1970 local time or 1/1/1970 UTC but will not affect the actual time stored. If you were to call ToUniversalTime on the deserialized DateTime it should come out to the same value regardless of whether the second number was +0500 or -0700.

Generally it’s good practise to convert a DateTime ToLocalTime before displaying to the user so the need to set DateTime.Kind is completely unnecessary and confuses the serialisation format. This confusing method of serialising DateTimes may have performance advantages in very edge case systems. In my opinion, most well designed systems would only ever work with DateTimes in UTC format, converting only at the time of display.

• Start your company with like-minded people who share your vision.
• When hiring, intelligence and experience are both important but intelligence is more important.
• It’s hard to not stress this enough. The best marketing is a great product. Pushing pixels and marketing gimmicks will only get you so far.
• Creating and marketing a new brand is very different from maintaining and marketing an established brand. Someone who’s able to sell ads for Sports Illustrated or cigarettes for Rothmans may have marketing skills applicable to a startup but it’s hard to know because the brand sells itself. It’s quite possible that they don’t have marketing skills at all.
• A good idea is important. Very important. But it is only 1% of what’s important. The other 99% is execution.
• Do not be afraid to go back to the drawing board. Bad product ideas can’t always be patched up.
• A technology startup should be staffed by people who love technology at all levels, not just engineering.
• Attract creative people. Flexible hours, casual dress, natural light, plants, artwork, fresh fruit are all relatively inexpensive.
• If you’re an engineer, don’t let people tell you to stop coding. There’s a reason why companies like Google insist that their technical managers spend at least 20% of their time coding. For engineers, coding is our own form of meditation.  You’ll be a more effective manager because engineers prefer to be led from the front.
• Admit you’re wrong when you’re wrong so you can move on and be right. Gently help others to do the same.
• You will encounter a lot of bullshit artists a long the way.  SEO specialists and management consultants are a complete distraction.  What they peddle is mostly common sense and what they charge for it is insane. Put your money and resources into product development.
• You may need to work with people who don’t know what they’re doing. Manage them if possible but don’t waste your time doing anything you don’t believe in or anything for anyone you don’t believe in. Life’s too short and you’re never trapped.
• Don’t outsource your engineering projects; even to other London agencies. Keep everything “in the family” because you’ll get much better results. Bad code can be much worse than no code.
• Do not ignore the fact that the most successful technology companies are started and run by engineers.  Engineers understand the importance of the product. Do not let investors or management sideline your engineers. Successful startups aren’t the ones that ignore their most important human capital.
• Do not let people who don’t love or understand technology try to tell you you’re wrong about technology.  These people are known as bozos. Follow your gut.
• Do not let people tell you you’re wrong simply because you’re younger. They could be right but they could also be very very wrong. Age should not be a factor. Again, follow your gut.
• It’s better to miss out on hiring good people than to hire bad people. One bad apple in your team can totally ruin it. Skills must go hand-in-hand with humility.  Having one but not the other is not good enough.
• Your science training is gold. Scientific thinking and methodology can and should be applied to product, design and management. It’s amazing how many business people don’t actually think.
• The best products are created by people with the need themselves. It’s incredible difficult to create a great product from scratch if you don’t have the need yourself.  Focus groups etc are unnecessary when you know what you want.  Often focus groups are used by people too afraid to make their own decisions and/or people who manipulate the results to further their own personal agendas. These people are also known as bozos.
• Focus on doing a few things and a few things well.  If you’re developing something you need yourself you will know what the most important features will be.
• Much of your time may be spent protecting your designers and developers from reactionary feature creep. This is an important responsibility, a fact of life, and must not be ignored.
• Be a perfectionist in everything you do but remember that you will need to ship. This means you’ll need to compromise on features. It’s better to have 5 features that are perfect than 20 that are below average.
• Make extensive use continuous integration (I have a soft spot for TeamCity). Compiling, testing and deploying should all be one click.  Stop everything you’re doing and spend an entire day setting this up if you need to.  You’ll be thanking yourself every day after.
• Make decision quickly and then re-make them if necessary.  Indecision (especially if it comes from the top) is very bad for productivity and morale.
• Find people who can earn your trust and then trust them. These may be business people, investors, designers and engineers. Don’t waste time with people you can’t trust.
• Work with other companies. Google & Facebook are two large tech companies with a significant presence in London and they both love working with startups.

Ideally you want your fstab to contain something like

Replace /dev/sd[a-z] with the appropriate disks or partitions that make up your array.

The last thing you need to do is change your mdadm.conf HOMEHOST setting to <ignore>. If you do not change this then mdadm on boot will mount your array as /dev/md/name_0 because the homehost of the array is empty and does not match the name of the mounting server. By adding this option, the integer suffix will only be appended if there are multiple arrays on the system with the same name.

Make sure you run update-initramfs after you change mdadm.conf.

sudo gdisk /dev/sdc
p (print/show)
s (sort)
p (print/show)
w (write)
q (quit)

After 14 months of iOS/Objective-C development, I’m now going to focus mostly on the Android app. It’s been 7 years since I’ve done full time Java development so this will be an interesting change . Over the last 4 years I’ve been a full time C++/QT developer, HTML/CSS developer, C# developer, Objective-C/iOS and now Java/Android developer.  It’s all over the place but somewhat exciting to mix up the work load with technical challenges of different flavours.

You may here a lot about Bloom.fm being founded by the same people as the short lived mflow.  In a way it’s true, it’s the same company and same investors but just to be clear: mflow was the brain child of some non-techie marketing types (led by a committee) allowed to run amok. Bloom.fm is the brain child of techie-designer-music types (led by myself) allowed to run amok.  Time will tell which approach is more successful

Why Bloom.fm?

With an almost zero-cost for Internet distribution, it makes sense for the music industry to encourage growth  of legal music consumption rather than increase (or maintain) prices to ward off loses from rampant piracy.  At Bloom.fm we use two strategies for encouraging growth.

The first is that we bet on the mobile computing revolution and have focused on creating the most usable music app for smartphones.  For many, a la carte shops are too expensive an option and streaming music apps are still too complicated and don’t give the “joy” that you may get from using other types of apps.  By designing an app from the ground up with mobile in mind we hope to capture a large chunk of users who haven’t fully gone digital yet.

The second is that we negotiated lower pricing.  For many people (especially students), £10 a month is too high whilst they’re studying but if we offer them a service that makes sense and at a fair price we hope that they will see the benefit of paying for music when they graduate and are in a position to pay for the premium subscription levels.

We don’t see streaming services cannibalising traditional music sales; we see music services complementing and growing the addressable market.

I wrote the compiler and interpreter for P++ at University back in 2000 as part of my second year programming languages paper. It was only supposed to be a 200 line assignment but I enjoyed learning about compilers so much that I added many advanced (advanced compared to PL/0) features such as:

* Strings

* Reference counted GC

* Lambda Expressions

* Big numbers

* Inline assembly/bytecode

* A modest library of core functions

As much as possible, most of the features and functions are written in the language itself. Big Integer support, math functions such as cos, sin, random and sorting functions were mostly an excercise in learning to implement the functions that almost always come for free with a language. There was a lot of reward in being able to implement complex libraries in a language I wrote myself.

Whilst going through very old disks, I discovered the code and have uploaded it to GitHub for posterity and in the hopes that it helps students and teachers learn and teach compiler construction.