Seventh Octave

We're Starters. We write about culture, design and the business of software.

We believe software should be beautiful and inspired. Follow us as we build @TechOctave.

Digital JavaScript Gauges TVD May 31

Post a comment

G'day Mate,

The latest version of our Charts Suite is here! :)

We've introduced a new example demonstrating how to create a digital gauge:

We also implemented a smarter way to format values using a flexible mask:

var sales = new Gauge("sales", {
    mask: "$#,##0.#0"
});

Thanks for your support everyone!

Are you working on any projects in the flight simulation field? Know a friend in the same? We'd love if you'd introduce them to our JavaScript Flight Gauges suite.

Release Notes: 2.3.0

GaugeJS

======================================== [Enhancements]

  • New digital example
  • List item
  • New number formatting mask

[Defects]

  • formatValue negative bug

JavaScript Flight Gauges Tian May 26

Post a comment

We don't know where most developers start, but this is where we start:

Artificial Horizon Attitude Indicator Gauge Concept JavaScript

Artificial Horizon Concept - December 2012

The Artificial Horizon gauge was the first concept we executed on and it all started with a single sketch on a single sheet of paper. The philosophers and proverbs often remark how great things start from small beginnings. We believe great software is no different.

What started as 0 lines of code and a dream is now 2,316 lines of code and a reality:

JavaScript Artificial Horizon Gauge

Today, we officially unveil, not just our JavaScript Horizon Gauge, but our entire suite of JavaScript Flight Gauges:

JavaScript Flight Gauges

After 12 months of R&D, over 4 months of bugs fixes and enhancements and 20,000 lines of code later, we're pretty damn proud of the results.

The Difference is Principle

We talk a lot about our six core principles of JavaScript development.

We built our JavaScript Flight Gauges on those Six Core Principles:

  1. Beautifully Illustrated
  2. Cross Browser Compatible
  3. Lightweight Footprint
  4. Vector Based for Crisp Zoom and Print
  5. Highly Configurable
  6. Framework Agnostic

We believe in those principles because great software doesn't happen by accident. Great software is forged in principle and blood and sweat.

A lot of companies will sell you software. Any software to be exact...

But, not many think about developer happiness from concept to code. Hell...! Many start with the code and try to work their way back to you. It doesn't work that way.

Let me repeat: IT DOES NOT WORK THAT WAY...!

We do things the principled way where ideas become concepts and before a single line of code is written, we ask a single question that underlines all six of our core principles, "How do we want a developer to 'feel' when using our components?"

A simple question, right? But, you'd be amazed at the responses. Yet, at the end of the day, we care only about one answer, "Great!" We want you to feel great...! If you don't, the API is refactored or the product doesn't ship. It's as simple as that.

That's why we're able to ship simple software that scales in complexity:

var horizon = new Horizon("horizon");
. . .
<div id="horizon"></div>

That's why we're able to develop APIs that make you feel great. Because just like great developers take time to develop, great software is not that much very different.

Great people develop on principle. Great software develops on principle too. Get some...!

Airline Transport Pilot License (ATPL) Essentials Study Guide TVD Nov 18

Post a comment

JavaScript Flight Gauges

The Wright Brothers were the first in flight. I write this post not very far from those historic grounds where they changed man's relationship with the sky and stars forever.

I'm hoping our guest today will do the same for you.

[Interview Questions]

Today we're talking with Stefan, an aviator and founder of the ATPL Essentials project whose aim is to build an open source library of ATPL study guides.

Stefan has had his private pilot's license for over five years now and shares with us today his passion for flight and the data that drives it. Stefan's latest project is a quick and targeted Airline Transport Pilot License (ATPL) Study Guide.

How old were you when you realized you wanted to become a pilot?

Quite old, actually! I was about to finish my studies of Aeronautical Engineering. Back then I believed I knew everything about airplanes. Then I met a friend who had his Private Pilot's License (PPL) for several years and was an avid aviator.

Talking to him, I found out that I knew a lot about the theory and close to nothing about the practice of flying. So after finishing my engineering degree, I decided to reward myself with my PPL license and enrolled in a flight school right after.

What was the first aircraft you ever flew?

I completed my training on a thirty year old Cessna 172. Nothing fast, nothing exciting, but very forgiving for the student pilot.

What's the fastest aircraft you ever flew?

After my PPL I flew a lot in Austria, where I almost exclusively flew on new generation Diamond aircraft. I used small planes already for business trips, so range, speed and reliability became an issue.

The next step into a deep addiction to flying was the Multi-Engine Piston (MEP) rating. I did it on a Diamond DA42 - a marvelous aircraft. No steam gauges, but an airliner like Garmin 1000 glass cockpit. Two piston engines, retractable gear. Beautiful to fly. You get cruise speeds of around 180kt, which makes for a nice travel experience.

Do you have your private pilot's license?

Yes, I have my PPL since five years now. Couple of months ago I finished my instrument rating, and currently I am about to finish my commercial license. It was quite a way here from PPL, but flying as a hobby is one of the most fulfilling things you can imagine. There is always this little bit more that you can get. You always learn something. On every flight. That's what keeps it interesting.

How long did it take you to study for the pilot license exam?

Coming right out of university with an aeronautical engineering degree, I had covered all the basic knowledge already. So I did my PPL fast pace in five weeks.

Sitting in the plane almost every single day, doing two sessions per day. It was not as easy as it sounds though. I imagined, I would do some flying in the morning, and spend the rest of the day at the beach.

Instead my day looked more like this: Quick breakfast, get to the airport, briefing, flying, debriefing - oh, it's lunch time already! Quick lunch, briefing, flying, debriefing - then maybe study an hour in the evening and fall into bed at 8pm.

As for the ATPL I took one and a half year for the whole theory. It is by far more expansive and I was doing it in parallel to a full time job, so there was only little time for studying.

What percentage of candidates pass the flight exam the first time? Is there a penalty for failing the exam? Do you have to wait 6 months or a 1 year to retake?

You have three attempts for each of the 14 exams. If you fail three times, there is some leeway to discuss with the authorities. Otherwise you would have to start all over. But I don't know anybody who failed completely.

Why a Flight Essentials study guide?

When I started studying for the ATPL, I was looking for a good book that explains the background of the ATPL exam and gives some context.

Several friends started out doing only question catalogues. When I joined them in their sessions, going through all the exam questions, I found out, that big parts of the books are irrelevant for answering the questions and other important building blocks for the questions were not even in the book.

Worse, in no single instance did the book tell me exactly what I had to know to pass the exam. So I decided to create my own study guides, like I'd done at university already. My friends asked me if they could use them, so I came to the idea of publishing them.

That's how the ATPL Study Guide was born.

What flight instruments does the Instruments Essentials cover?

On the one hand it covers all the basic flight instruments, Speed Indicator, Artificial Horizon, Altimeter, Turn & Bank Indicator, Horizontal Direction Indicator and Vertical Speed Indicator. On the other hand it gives a rough overview of Alerting &Warning Systems, Autopilot and some additional information about the physical principles behind them.

What is the most difficult instrument to master?

In terms of studying, the Airspeed Indicator is not as simple as it sounds. There are many different relationships between Indicated, Calibrated, Equivalent and True Airspeed - depending on altitude, temperature and speed.

In terms of flying, the Compass can be a bit tricky. Normally you don't use the compass, but if your HDI is out of service, you have to rely on the little ball compass. The Compass is affected by acceleration and turning errors, which always have to be considered. By itself, is just a very flimsy device - shaking in turbulence, which does not make it easy to follow a certain heading.

After the certification is complete, what do you do next? Are there any more exams?

I have successfully passed all my theory exams and went for the Instrument Rating right after. Right now, I am two sessions short of finishing my CPL training.

After that? Who knows!

I definitely want to spend some time in cockpits, but I guess not in commercial airlines. I think best for me would be to fly for a small private executive operator. This would give me some time to finish the ATPL Essentials Study Guide and pursue some other projects I've been working on.

What other projects are you working on? What's next for you?

I can't tell much about that now. It's a project about providing better and cheaper information to pilots.

In the US, flight is quite transparent already. But in Europe it can be super annoying to find out simple things like the runway length or opening hours of an airport.

Many people have to pay for that information. I think this is inherently wrong and there is a lot of space for improvement.

Save Raphael SVG Chart As Image TVD Nov 11

Post a comment

We work with the best developers in the craft. They push the envelope. They make the right decisions. Do the right work and ship.

Save Raphael SVG As Image

In that environment, a lot of great minds ask the same great questions. One of those questions often sounds like this, "How do we save our SVG chart to a PNG image?"

Saving SVG to PNG image turns out to be a very popular question. Though, not surprisingly, because the browser is involved, it is not an easy on to answer.

Save Raphael SVG To Image Client Side

First, you'll have to have an HTML5 element to hang your SVG on:

<div id="sales"></div>

and a HTML5 button to trigger the download event:

<button id="createImage">Create Image *.png</button>

Next, you'll have to have an SVG graphic to load into the HTML5 element. Here we'll use our JavaScript Gauges:

window.onload = function() {
    var sales = new Gauge("sales");
};

At this point, you will have an SVG object loaded into your HTML5 node. Then follow this algorithm to setup the SVG image download process.

Save SVG To Image Algorithm:

  1. Get the svg instance
  2. Create the canvas element
  3. Load the canvas element with our svg instance
  4. Save svg to png
  5. Clear the canvas

Here's the SVG To Image Algorithm in Code:

//Create PNG Image
document.getElementById("createImage").onclick = function() {
    //Get the svg
    var svg = document.getElementById("sales").innerHTML;

    //Create the canvas element
    var canvas = document.createElement('canvas');
    canvas.id = "canvas";
    document.body.appendChild(canvas);

    //Load the canvas element with our svg
    canvg(document.getElementById('canvas'), svg);

    //Save the svg to png
    Canvas2Image.saveAsPNG(canvas);

    //Clear the canvas
    canvas.width = canvas.width;
};

Step 3 uses the Canvg library. Canvg is a SVG parser and renderer. It takes a URL to a SVG file or the text of an SVG file, parses it in JavaScript, and renders the result on a Canvas element.

Step 4 uses the Canvas2Image library. This is a small library that lets you easily save a HTML5 canvas element as an imagefile.

Pros

The pros are you get a 100% client-side solution to saving Raphael SVG to PNG image. Which means less server load and more front-end awesome.

That's the good news...

Cons

The bad news is the image is downloaded without a file extension. Also, the limitations with browser mime type control, you cannot give the image a custom file name.

If you're paying attention, you know those are pretty BIG cons.

Save Raphael SVG To Image Server Side

When you want to set a customized filename for the generated PNG file, you have to send the data:uri string from the canvas.toDataURL() element onto server side using Ajax. Then rewrite the response headers and send back the browser. Here's a good article summarizing the server-side technique using CoffeeScript and Ruy.

Conclusion

Using client-side only is not an option yet because the browser technology just isn't there. What you'll want to do is combine both client-side and server-side techniques to get the maximum customization.

Something like...

Save SVG To Image Algorithm:

  1. Get the svg instance
  2. Create the canvas element
  3. Load the canvas element with our svg instance
  4. Ajax the canvas.toDataURL() results to your server
  5. Rewrite the response headers and send back to the browser

Using Ruby and Rails would look something similar to:

# svg_controller.rb
class SvgController < ApplicationController
  require "base64"

  def show
    @svg = Svg.where(id: params[:id]).first
    respond_to do |format|
      format.png {
        headers['Content-type'] = 'image/png'
        headers["Content-Disposition"] = "attachment; filename=\"chart.png\""
        @result = Base64.decode64(@svg.content.gsub('data:image/png;base64,', ''))
        render :text => @result
      }
    end
  end
end

That will get you the customization you need.Step 5 is an implementation detail. Use Ruby, J2EE, .NET, Python, use whatever you need to get the job done and you will have your victory.

Happy Coding and Godspeed!

Raphael.js JavaScript Charts 1.2.4 TVD Nov 03

Post a comment

Hi Everyone - The latest version of our JavaScript Charts Suite and JavaScript Gauges Suite is here! :)

We're very excited to bring you what we feel is a beautiful API documentation set based on the wonderful Raphael.js open source documentation framework.

We love the look and feel. Every time we use the new documentation it's like spending time with an old friend. We hope you come to feel the same way too:

TechOctave JavaScript Charts and Gauges API Documentation.

Also, this release fixes a major bug limiting the number of Columns and Bars on the ColumnChart and BarChart - along with misaligned label positions. See, example of bug report showing shifting labels and bars:

Charts shifting bug screenshot.

Release Notes: 1.2.4

TechOctave Charts Suite

========================================

[Enhancements]

  • New API Documentation in /docs folder
  • Implemented Series Charts capability in both ColumnChart and BarChart charts
  • Added barSpacingFactor property to ColumnChart and BarChart charts

[Defects]

  • Fixed issue where group label was shifted and not aligned for large amounts of columns/bars.
  • Fixed issue where columns/bars would shift off axis for large amounts of columns/bars.

[API Improvement]

  • Deprecated hasLines from BubbleChart properties.
  • Deprecated lineColor from BubbleChart properties.
  • Deprecated lineStrokeWidth from BubbleChart properties.

Happy Coding Everyone! Chief Geek Out!

Project TALOS - Real "Iron Man" Suit Commissioned by US Army TVD Oct 09

Post a comment

The tech behind the Iron Man suit is near. About a month ago, the US Army issued a broad request for proposals for a Tactical Assault Light Operator Suit (TALOS) for use by Special Operations Forces.

Keloid from BLR_VFX.

From Greek methodology, Talos was a mythical man made of bronze who protected the island of Crete from pirates and invaders.

With it, the Army hopes to give soldiers super human abilities like super strength. Even enhanced vision, including night vision and heat vision. The suit will also be bullet proof - meaning the super soldier could literally walk into a stream of bullets.

If successful, the TALOS project could literally change warfare as we know it. For ages, military innovation has drove the ever evolving civilizations of mankind.

The club and spear gave early mankind dominance over its Neanderthal competition. The chariot dominated the Nile, transforming Nubian Kings to Pharaohs. From the bosom of Greece to the steppes of Asia, the Macedonian Phalanx took Alexander The Great from boy King to Ruler of the Known World:

The Roman Legion turned an upstart King in the foothills of Italy into the greatest super power the ancient world had ever known. Not many generations later, the world hailed Caesar from all its four corners:

Military superiority spreads progress at the civilization level. Indeed, it brings change to the very face of a people. History is steeped in such lessons. Mankind the progeny of the teacher.

The Bowman on horseback turned a young Temujin from orphan to the great Genghis Khan, allowing him to conquer every stretch of territory from China to the eastern flanks of Europe. To this day, I dare you to travel to Kazakhstan and not see the face of Khan in all you survey:

Guns, Germs and Steel turned the Royal Family of Europe from Kings to CEOs - overnight successes. And from people to property for those who hadn't the good sense to keep pace:

And here we are...

From boomstick to the longrifle to the M1 Carbine to the AR-15 semi-automatic rifle. The thing is every nation has these nowadays.

The Royal Families of Southeast Asia have them. The Royal Families of Subsaharan Africa have them. The Royal Families of Europe have them. Even the Pope has them. Every Republic has them: The United States, China, Japan, Russia, France, England, Australia, Trinidad, South Africa, Venezuela, Chile, Brazil, Sweden, Switzerland...

You get the picture...

The TALOS program is the new evolutionary leap in modern warfare. If successful, it will be the guns and steel of our generation. If successful, it will mark a competitive advantage in military theatre. It will be the one element of warfare not easily reproduced by competing nations.

And it would make for compelling leverage.

You see, the thing with modern warfare is its all so very boring. Push a button, drop a bomb - boring. Close Quarter Battle (CQB) - boring. What modern warfare needs is some flare.

Roman Legion with 5,400 soldiers in 11 cohorts - flare! 12,000 Macedonian Hoplites in Phalanx formation - flare! Mongol Horde 50,000 strong - flare! 10,000 Spartans, commanding 50,000 free Greeks - flare!

The TALOS system will definitely be flare. I can't imagine dropping even a squadron of super soldiers on an enemy capital. The results would be devastating.

But how would the first generation TALOS system look? Here's a potential imagining from the BLR VFX Team that brought us Keloid:

The Mech Suit:

The Super Solider:

How do you think the TALOS system will look?

But For Stack Overflow TVD Oct 07

Post a comment

Sometimes I wonder where we would be without Stack Overflow. I also wonder how many truly remember the days before it existed. People see old, poorly designed software forums and think, "Ick!" Today, you're not one of those people. Today, you're one of the people who remember when there weren't any software forums at all.

MSDN Subscription Library

No Stack Overflow. No software forums. No Internet.

Microsoft Developer Network

Back in the day, some guys made a small business at University over the control of information. You'd seem 'em around campus, strolling around the engineering buildings...

"Pssst. Hey my man! I got MSDN Library and Visual Studio 2000. Yours for only $5 dollars." Boom - That's your ticket to a superior IDE and faster homework completion, so you can't say no.

CD ROMs. We carried the precursors to forums and Stack Overflow on physical disks - and we were happy for them too. How crazy is that?

Then we graduated.

If you were heavy into C++ and worked at an established company, you probably had access to an MSDN Subscription. Which means you could load code use "examples" into your Visual Studio IDE. And when I say, "examples" I mean that loosely.

The answers were typically academic. But it was more that it...

Over the years, as developers, we've come to develop a certain cultural ethos. An ethos built of principle of exploration and growth and progress. An ethos that self-directs those committed to the craft towards stronger and stronger skill development. I like to think about it as Technological Darwinism and the best of us have come to frequent places like Stack Overflow and others as a sort of modern day medieval tavern.

Only our drink is not of spirit or ale, but of knowledge. In the end, we've developed a hive mind as such. One of which the answers we seek seem like questions we would've asked ourselves. Because we have. Countless times across countless cubes and continents.

And when your time comes, it is as if the answers wait for you. At the rate of thousands upon thousands, developers ask the very questions they themselves would ask. The answers of which are forever memorialized and freely distributed for the next wave of developer synaptic activity.

That's the fundamental difference between Stack Overflow and what came before it. With Stack Overflow, you felt like "you" had asked the question yourself. In all that came before it, it felt like "they" had no idea even what to ask.

And then there was Stack Overflow

Before Stack Overflow, documentation wasn't born of real world scenarios and pain points. So there was never an answer to the question "you" had. Just some brisk points on what "some guy" thought was a cool exposition. Or some vague reference to some static documentarian to check "over there".

But FOr Stack Overflow

Real world examples. Real world answers. Accessible and freely distributed. That changed everything. In fact, I fundamentally believe that changed our entire profession all together.

I mean, think about it.

What other profession lives and breathes its craft like developers do? Do accountants go home at night and think about Tax Law. Do lawyers gather every few months to speak and meetup at Code Camps and Conferences? Do health inspectors spend weekends trying to analyze the best refrigerator temperature? I doubt it...

It was our free dissemination of information and with it knowledge that bound us as a community, irrespective of individual ambition. And with it a zeitgeist was born, a developer zeitgeist.

And isn't that what makes places like Stack Overflow and Code Project so addictive. It's not that you've found the answers you seek, it's that you've found yourself.

The CD ROMs and MSDNs and forums were never our voices. They weren't from our breath of experience. They did not breathe life into our experience.

Stack Overflow is our voice. It brought meaning to our experience.

The Reality of Being a Software Developer TVD Sep 26

Post a comment

I get asked a lot, "What's it like to be a software developer?" Sometimes its easy to answer, but there are days the answer gets a wee bit more interesting. Those days remind me a lot of this clip from Malcolm in the Middle...

And I get to wondering, "What if Breaking Bad is just Hal having a bad dream?"

Cool Error, Bro TVD Sep 20

Post a comment

Some error messages simply need no introduction:

A SELECT statement with no GROUP BY clause contains a column name and a column function in the SELECT clause, or a column name is contained in the SELECT clause but not in the GROUP BY clause.

Developers Developers Developers Developers...YES! TVD Sep 18

Post a comment

Microsoft announced Steve Ballmer to retire in 12 months. Personally, I haven't purchased a Windows box for almost a decade. But, here's to you Steve and all the crazy we'll miss:

Ninjas Considered Harmful TVD Aug 31

Post a comment

Please stop posting jobs for "_ _ _ ninjas." It is disrespectful to the ninja community, and confusing for ninjas actively looking for work:

Code & The Pit of Hell TVD Jul 30

Post a comment

The fine folks over at LayerVault have released PSD.rb, allowing Ruby developers to easily work with Photoshop documents:

Ruby Photoshop Parser

If you use and love Ruby like we do, then you love this idea like we do. What once was a black box is now open for innovation. What's more is the surrounding context; Mans ever compulsion to control his environment, no matter the cost.

All great narratives have their version of the pit of hell. If you've ever read Dante's Inferno or did the same thing over and over expecting a different result, then you too have danced with the devil.

Development is no different.

Except our pit of hell is masked in ones and zeros and entices with songs of victory very brave few can resist. The Dark Lord Cthulhu himself constantly double dog dares us to parse HTML. Once a week we try to reinvent JavaScript.

Madness.

Photoshop's PSD format is not our favorite file format either. For many, to parse PSD is their last dance with sanity. It's not easy.

Many simply go mad.

And in their fall is a glimpse into honesty and bravery few seldom experience. I wanted to share that experience with you. Here's a code snippet from the last guy who tried to parse PSD in the Xee project:

===================================================

uint32_t chunklen=[fh readUInt32BE];

off_t nextchunk=[fh offsetInFile]+((chunklen+3)&~3);

At this point, I'd like to take a moment to speak to you about the Adobe PSD format. PSD is not a good format. PSD is not even a bad format. Calling it such would be an insult to other bad formats, such as PCX or JPEG. No, PSD is an abysmal format.

Having worked on this code for several weeks now, my hate for PSD has grown to a raging fire that burns with the fierce passion of a million suns.

If there are two different ways of doing something, PSD will do both, in different places. It will then make up three more ways no sane human would think of, and do those too. PSD makes inconsistency an art form.

Why, for instance, did it suddenly decide that these particular chunks should be aligned to four bytes, and that this alignement should not be included in the size? Other chunks in other places are either unaligned, or aligned with the alignment included in the size. Here, though, it is not included.

Either one of these three behaviours would be fine. A sane format would pick one. PSD, of course, uses all three, and more.

Trying to get data out of a PSD file is like trying to find something in the attic of your eccentric old uncle who died in a freak freshwater shark attack on his 58th birthday. That last detail may not be important for the purposes of the simile, but at this point I am spending a lot of time imagining amusing fates for the people responsible for this Rube Goldberg of a file format.

Earlier, I tried to get a hold of the latest specs for the PSD file format. To do this, I had to apply to them for permission to apply to them to have them consider sending me this sacred tome.

This would have involved faxing them a copy of some document or other, probably signed in blood. I can only imagine that they make this process so difficult because they are intensely ashamed of having created this abomination.

I was naturally not gullible enough to go through with this procedure, but if I had done so, I would have printed out every single page of the spec, and set them all on fire. Were it within my power, I would gather every single copy of those specs, and launch them on a spaceship directly into the sun.

PSD is not my favourite file format.

if(sign!='8BIM') break; // sanity check

===================================================

But there is a happy ending to this story...

The truth is for all our shortcomings as developers, every line of code we commit contributes to the greater good. With every project and every passion we lay the foundation for a brighter tomorrow.

Without the hustle and code of the Xee developers, who knows where we might be with PSD.rb or PSD.js or PSD.*

We contribute to the greater good...Remember that.

When you're down-and-out...Remember that. When it's time for you to push back on that project deadline...Remember that. When the code is too hard, the frustration too great...Remember that.

Remember that after all the hustle, just beyond the field of "finished" is a brighter tomorrow for all of us.

Code for the moments that take your breath away.

Welcome to someday. TVD Jul 26

Post a comment

Someday - CompuServe

C# File Binary Serialization & Tender Love Making TVD Jul 24

Post a comment

.NET is a ghetto.

People say the world is getting smaller. That there just isn't that much left to explore. I suspect the people who say that haven't coded yet.

The other day, we spent an absurd amount of time trying to find the best way to serialize a simple document for use in an XML Web Service call. Our wish is that this code snippet helps someone else.

Serialize Binary Documents

Here's how we serialized a binary file to a string based format in C#:

string filePath = @"C:\OBEY\Word.doc";

byte[] file = File.ReadAllBytes(filePath);

string serializeDocument = Convert.ToBase64String(file);

High level, the steps are:

  1. Get the document's file path
  2. Load the file into a byte array
  3. Convert the byte array to a Base64 string

It's crazy, during research, everyone wanted to talk about serializing POCOs* to send across the wire. EVERYONE. But, that's only one application of serialization. How about the most simple use case, serializing a simple document.

Well, now you know how.

*As an aside, if you're not familiar with the term Plain Old C# Object, I encourage you to read up on design principles in leading "Enterprise" Architecture. It's truly a fascinating read. And yes, I know POCO stands for Plain Old CLR Object, but who are we kidding right? :)

Deserialize Binary Documents

Deserialization - that is converting a Base64String to a binary document - is just as simple. Here's how:

byte[] document = Convert.FromBase64String(string);

Where the variable string is a serialized Base64String string. From there you can make tender love to the document. Or whatever else you were planning to do.

'Till next time...Peace, Love and Happy Coding! :)

On Responsive Architectures & JavaScript Gauges TVD Jul 16

Post a comment

Use Responsive Web Design breakpoints and each Gauge's refresh method to build the right JavaScript Gauge for the right resolution.

Responsive Architecture

We're Deprecating The AutoResize Feature

Autoresize was written with the best of intentions. It was early 2010. Barely anyone had heard of the term Responsive Web Design (RWD) and we were trying to help an early customer with a "very dynamic website" - as it was described. So we wrote autoresize with the goal to calculate our Gauge's DOM container and resize accordingly.

It worked for the customer's specific use case. But we now believe it was a bad approach overall because only the actual developer can 100% know what Gauge size will work for him.

Our Gauge (any component really) can only approximate the best dimensions since the DOM container's offsetWidth and offsetHeight doesn't always return the expected results and that's if those properties even exist for the specific browser - That's the best case.

Worst case is we, inadvertently, deny our developers the needed control of the end user experience. Either result is no longer acceptable for us.

The Recommendation

Fast forward 3 years later and we've made leaps and bounds towards our understanding of RWD. Using the discipline of Responsive Architecture and techniques like Flexible Grids, Flexible Images and CSS3 Media Queries, we can write an application once and it will run in every environment we target.

With RWD, we the Developer, decide which breakpoints - a breakpoint is a value at which a layout adapts - we will design for. Once we decide that, then we design how we want our web application to look for each breakpoint.

Using these techniques, the same app you write for a desktop can run great on a mobile device. The UI will simply look crystal clear at any breakpoint because our JavaScript Gauges are based on vector graphics and are scalable.

Once the UI hits a breakpoint, simply update our Gauge with the width and height that looks best for that breakpoint:

var knots = new Gauge("knots");
. . .
knots.set("width", width);
knots.set("height", height);
. . .    
knots.refresh();

Using a Responsive Architecture will set your application up for success - You don't need autoresize to make that happen. We'll keep autoresize in for backwards compatibility, for a few releases at least, but we'll no longer promote it as a feature.

Instead we'll promote refresh and RWD for best results - Which was the real intent of autoresize, however lofty the goal was. Our Gauge API has outgrown autoresize. Frankly, the web has outgrown autoresize.

Use Responsive Web Design breakpoints and each Gauge's refresh method to build the right Gauge for the right resolution and Code for the moments that take your breathe away.