If you’re reading this, then that means I’ve finished upgrading my website to Gatsby 2. Gatsby is a static site generator that uses React and GraphQL to build the entire website as a set of static HTML files, which I used to build this version of my website. Version 2 has a number of really promising improvements like a component for querying GraphQL from anywhere and improved Webpack and Babel support (which will hopefully let me start trickling in some TypeScript).

The well documented migration process was not as smooth as I’d hoped, but that was to be expected. Gatsby does require some comfort with debugging Webpack and React apps before you can really use it well, and this was no different. The biggest reason for this was that I had a .babelrc file at the root of my project which was causing some difficult to debug problems (and ones with no search results). Ultimately the most important thing I did was to just throw that file out and replace it with the default, a step that is not emphasized enough in the docs. It certainly could have gone much worse and once I discovered this source of my problems, it was much smoother sailing.

Overall the migration took about 8 hours. This included time spent following the migration guide and debugging problems, as well as modernizing some of the new tools in Gatsby 2. Namely, the use of the new StaticQuery API for inlining queries. An example of this is that lovely little photo of me that’s on every page. Previously in Gatsby 1, each page had a single GraphQL query that could be run, so everything had to be shoved in there, including for images like that photo. That meant each page had duplicated query logic for fetching that image. Now, that has been rolled into a component that uses StaticQuery to fetch the image, which simplifies the page-level queries quite a bit. There’s a few ways I use that kind of pattern to clean up the site. You shouldn’t notice anything, but it makes working on the site here much simpler, especially if I want to add something that relies on a query.

I’ve been avoiding ripping this bandage off for awhile, but now it looks like it’s done and I can start using the new features. Gatsby’s got a rich plugin library, including some powerful integrations with service workers. I had this enabled originally but shut it off because it couldn’t detect cache changes very well with it, but Gatsby 2’s updated version of Webpack should make that more viable. There’s also some new query tracing tools which will help me get build times down; right now it takes about 3 minutes to build on the (admittedly very slow) server I run it on, and I’d like to get that to be under a minute. And I am dying to start moving stuff to TypeScript, which Babel 7 now supports.

Congratulations to the Gatsby team on shipping and doing such a huge release!

In my last website post I talked about my plans for setting up website notifications on AWS Lambda and DynamoDB. The idea is that a function on AWS Lambda would get called when the site had an update, which would fetch all the site data, diff it against the previous state, and determine which pages actually changed. Those changes would get saved to AWS DynamoDB, which has a streaming feature that other AWS Lambda functions can be triggered by for each event. Multiple Lambda functions (one for each service) would get those updates and fire off whatever integration was necessary for each service.

This would put the burden of running the service and hosting the data to Amazon’s ops crew, which is undoubtedly better than what I would have set up. As long as I stayed within the limits of the AWS free tier, which looked pretty decent, I would be able to run this in perpetuity, right?

Read More

Adobe is finally putting an end to Flash Player. They’ve announced they’re stopping development of the mobile Flash Player, which is where the future of tech innovation is heading, and the writing is on the wall for desktop Flash Player as well. This is a good thing for a myriad of reasons, both technical and political.

However, it is important to remember that Flash drove much of the innovation on the web as we know it today. When Flash was conceived over a decade ago, the web was a glimmer of what it is today. Creating something visually impressive and interactive was almost impossible. Flash brought the ability to do animation, sound, video, 3D graphics, and local storage in the browser when nothing else could.

Without Flash, MapQuest would not have been able to provide maps for years before Google did in JavaScript. The juggernaut YouTube would not have been possible until at least 2009, four years after its actual launch. Gaming on the web, which has been around as long as Flash, would only now be possible a decade later. Flash enabled developers to create rich user experiences in a market dominated by slow moving browser developers. Even in 2011 Flash exists to provide those more powerful apps to less tech-savvy people who still use old versions of Internet Explorer.

Flash Player itself seemed like a means to an end. Macromedia, and then Adobe who acquired them, sells the tool that you use to build Flash content. Thus, Adobe’s incentive was not to build a great Flash Player, but a pervasive one that would sell its tools. Its technical stagnation provided a market opportunity for browser developers to fill in the gaps that Flash provided. As a result it has a huge market dominance in tools for building rich apps for the web, tools HTML5 lacks.

This puts Adobe in a unique position. As HTML5 continues to negate the need for Flash Player, Adobe has the tools for implementing Flash within HTML5, and the market eager for those tools. Hopefully this move signals that Adobe will be moving in this direction. Because the web DOES need great HTML5 tools for people who aren’t savvy in JavaScript, especially for the people who used Flash to do it previously.

HTML5 offers developers the ability to build high-performance, low-power apps and experiences. Browser innovation has never been faster; Apple, Google, Microsoft, and Mozilla are all competing to bring the best new features to their browsers in compatible ways. But they’re just now filling in many features Flash Player has had for years. Adobe can harness this to help build a better web, and few others can. Hopefully they seize this moment.

VillainousStyle is a drawing library for defining a visual style from a chain of individual drawing instructions. Each instruction modifies the drawing context to perform common operations; such operations include shadows, fills, borders, and shapes. It allows for multiple style sheets which can be used to theme an application in multiple visual contexts. VillainousStyle sits on top of CoreGraphics, and does not use WebKit for rendering at all. It is a fork of the VSStyle and VSShape classes, originally from the Three20 project.

Stylesheets

VSStyleSheet is an abstract superclass for a set of styles. Subclass it and add methods for each style you wish to add. You will likely want to create a protocol for your styles to implement, to ensure that your stylesheet implements all the necessary styles.

There is a global stylesheet, which can be thought of as the “active” stylesheet. Call +[VSStyleSheet setGlobalStyleSheet:] to change the active theme, which will fire a VSStyleSheetChangedNotification. When that gets fired, you’ll want to tell your views to update their styles and redraw.

Styles

Styles affect drawing and positioning. Most will affect the next VSStyle objects in the chain.

  • Fills

    • VSSolidFillStyle – Fills the current shape with a solid color
    • VSLinearGradientFillStyle – Fills the current shape with a gradient between two colors
    • VSReflectiveFillStyle – Fills the current shape with a glossy-style gradient between two colors
  • Borders

    • VSSolidBorderStyle – Draws a border around the current shape with a solid color
    • VSBevelBorderStyle – Draws a beveled edge border for a 3D effect around the current shape
    • VSFourBorderStyle – Draws a border around the current shape with four colors, one for each edge
  • Shadows

    • VSShadowStyle – Draws a shadow behind content with a given color, blur, and offset
    • VSInnerShadowStyle – Draws a shadow inside the content with a given color, blur, and offset
  • Positioning

    • VSBoxStyle – Adds a margin or padding to the content area
    • VSInsetStyle – Adds edge insets to the content area
  • Content

    • VSTextStyle – Draws text inside the current shape
    • VSImageStyle – Draws an image inside the current shape
    • VSMaskStyle – Clips the drawing area to an image mask
    • VSShapeStyle – Clips the drawing area with a VSShape object

Shapes

Shapes affect the fills and borders, but do not clip the content styles.

  • VSRectangleShape
  • VSRoundedRectangleShape
  • VSRoundedLeftArrowShape – a rounded rectangle with a left-facing arrow
  • VSRoundedRightArrowShape – a rounded rectangle with a right-facing arrow

Future Ideas

  • iPhone static library
  • Cappuccino library
  • File-based stylesheets that can be read/written from VSStyleSheet objects
  • GUI builder for styles
  • More styles!
Link

This one is for all of those developers out there who scoff at JavaScript. This is a working neural network algorithm in JavaScript used for ripping apart CAPTCHA images (in this case, from Megaupload) and deciphering them. This is really sophisticated stuff, and even though Megaupload has some pretty easy CAPTCHAs, this should be pretty easily adaptable to other CAPTCHAs.

Link

There’s been quite a bit of misunderstanding about what Palm’s new WebOS is, versus what it isn’t. So I’d like to dispel some of the questions surrounding it from the information I’ve been able to find on it. There isn’t much I was able to find (not surprising, as the thing was just announced today), but we can draw some conclusions from the information.

From Web Apps to Widgets

Many people will respond with derision at the fact that applications in WebOS are built with HTML, CSS, and JavaScript; given the state of most web applications today, this isn’t hard to understand. However, the biggest reason web apps are crap compared to their desktop equivalent is that web apps have no integration with the host OS. Which means that web apps have a tough time dealing with multiple OS windows, the clipboard, and offline access.

When Apple released Tiger, they shipped with it the popular Dashboard interface. Inside were miniature applications which were also written with HTML, CSS, and JavaScript. There was a slight difference, however; Apple included the means to integrate the Dashboard with JavaScript. One example is how a Dashboard widget will display its settings via a smooth, GPU-accelerated 3D animation where the 2D widget flips over. This is possible because Apple included JavaScript hooks to perform this animation. But the core tools were just the same – HTML, CSS, and JavaScript.

The Mojo Framework

WebOS applications are much more sophisticated than Dashboard widgets, and certainly more so than regular web applications. This is because WebOS includes a set of tools for creating apps, called the Palm Mojo Application Framework. This, at its highest level, is conceptually similar to Cocoa Touch on the iPhone; it provides common functionality to all applications. It’s what will provide all the common code on the device, from data manipulation of stuff like your calendars to the whizzy animation effects you’ll see throughout the interface. It’s the reason that, in most iPhone apps, the scrolling behavior feels exactly the same.

So, from what I can tell, the Mojo framework is an implementation of all of these ideas, using JavaScript as the programming language, and using HTML5 and CSS for drawing to the screen. Despite there being very little information, they do mention the following features on the developer website:

  • apps are installed and run on the device,
  • apps are designed to be multitasked and run in the background,
  • apps have full access to gestures and the touch screen,
  • apps can use a Growl-esque system to display user notifications,
  • apps will have access to sqlite databases for data storage (part of HTML5), and
  • apps can exchange data via a common messaging mechanism.

The Performance Argument

“But won’t it come down to speed?” Yes, it will. However, WebOS is based on WebKit, and likely is using the latest enhancements from the SquirrelFish project. There is a battle royale going on right now between the developers of WebKit, Firefox, Chrome, and Opera for fastest JavaScript interpreter, which means that JavaScript is only going to get faster and faster.

Why go with JavaScript? It provides a low barrier to entry; nobody really needs an SDK to write apps. It makes it very easy to sandbox apps, as the underlying operating system is still invariably written in some form of C, and JavaScript provides no way to break that barrier. And many other reasons, which I talked about last year before the iPhone SDK came out.

tl;dr: JavaScript is just a language. Palm used that to build a system for making applications. They’re nothing like web apps.