Mike Zornek

Becoming an Accessibility Ally: My Early Journey and Resources

mike@mikezornek.com (Mike Zornek) — Thu, 12 Jun 2025 10:00:00 -0400

Here is a hard truth: while I want to be viewed as an ally to accessibility, I probably would not score very high if you judged me by my actions. In the past, I’ve worked a little extra to find the correct semantic HTML tags to use in various situations. I have included the random image alt attribute but not much else.

I had a few peers at my last employment who were more active regarding accessibility. While management or QA rarely prioritized fixes or rejected a PR because of failed accessibility access, there was some effort and discussions in the trenches. I remained mostly on the sidelines, with only one notable unit of work where we evaluated different approaches to keyboard navigation. (This was for a custom, searchable <select>, which was used for page navigation. I was refactoring it from a messy Alpine implementation to a more cleaned-up LiveView implementation with JS command patterns.)

Having left that job, the interest in improving my accessibility skills remained, and last week I took action working through Frontend Masters’ Website Accessibility course by Jon Kuperman.

In today’s post, I’ll share some things I learned from the Website Accessibility course and a few tools and resources you can look into if you are interested in leveling up as well.

Course Review and Takeaways

This is primarily a video course with some limited live code exercises broken down into the following sections:

1. Accessibility Overview

Provided a review of what accessibility is all about, historically and more specifically related to computers and the web. There was a brief review of legal compliance needs and the various web standards that drive accessibility specifications.

The section ends with installing a screen reader, which will be used in the next section. For me, it was the built-in macOS VoiceOver tool, but other tools were provided for Windows and Linux.

2. Semantic HTML & Assistive Devices

Reviewed image alt text, semantic HTML, the cost and complexity of using <div> elements as intended buttons, and screen reader-only content. We then use our new screen readers to work through some examples, demonstrating how the screen readers consume content using good examples, bad examples, and encouragement to make the bad examples work better.

I’ve used VoiceOver a little in the past. We did some very rudimentary demos of it when I taught the iOS classes for Big Nerd Ranch, but it was never something I leaned on much professionally. The space to use it on some basic exercises helped me greatly. I feel comfortable now, enabling it to walk content and even flip through rotor menus to see how it can navigate.

3. Managing Focus and Tab Order

This section reviewed keyboard navigation using tab order to influence the flow, what focus is all about, and how the focus should be visualized. I appreciated the candor of the instructor in reviewing what the accessibility standards ask for regarding focus visuals and how this often feels confrontational to some design teams who want to execute a particular look.

4. ARIA Labels & Roles

Right from MDN:

Accessible Rich Internet Applications (ARIA) is a set of roles and attributes that define ways to make web content and web applications (especially those developed with JavaScript) more accessible to people with disabilities.

In this section, the instructor reviewed some examples of ARIA. These specifically relate to me as a web application developer, as I often develop component abstractions that might not fit the standard markup. I can use ARIA roles and labels to decorate my markup to inform assistive devices better.

There was an exciting review of ARIA live regions, which is a way you can decorate areas of the page that are updating in real-time (like LiveView things). You can even use a politeness setting to help share if the update should interrupt the flow of content or be presented at a break.

5. Color Contrast

Reviewed how a lack of color contrast can impact people’s readability with low vision. This section also talked about how you might choose contrasting colors with intent but get poor outcomes for people with color blindness.

An example was shared from a Bloomberg article titled Designing the Terminal for color accessibility:

Notice how the design chooses red and green with a wanted contrasting visual concept, but when viewed by people with color vision issues, they will not see that contrast. To make it work for those people, choose different colors or offer alternative themes.

6. Accessibility Tools & Testing

The course closes by providing lists and demos of various tools (which I will include in my own resources section below).

Course Review

I enjoyed the course greatly. The video runtime total was about 2.5 hours and I probably spent 5-6 hours working through the content, pausing to read up and try things out. It is an excellent fit for the introduction I was looking for. The exercises were helpful but felt a little too open-ended for me. (I am extremely biased, however, to my own teaching patterns from my Big Nerd Ranch days.)

I was not an active paying Frontend Masters member before taking the course. I will likely keep it going for a few months and have bookmarked some follow-up course ideas. (I joined back in 2018 when I was first trying to figure out my exit plan from Apple, and took a few React and other web dev courses.)

In addition to the paid for courses, Frontend Masters has lots of smaller tutorials and blog posts that might interest you.

Resources and Tools

With the course behind me, I wanted to apply what I’ve learned and start with my blog as soon as possible.

One of the first tools I used was the axe DevTools Firefox extension. This extension can help point out accessibly concerns (like label-less form elements, color contrast issues, and way more) with good notes on how to approach each problem. The company behind this is Deque (which is actually where one of my accessibility-fluent peers went to work). A bit of a warning, many of the tools Deque offers have open source availability, but their website kind of steers you to buy the paid-for version, so be prepared to go hunting a bit.

Another tool I relied on was RocketValidator. This tool will accept a single URL, validate it and then follow the site links to provide a full review of your site. This is a paid tool, but you can use a very helpful and usable free tier to get started.

See the initial report for yourself. (Note: this is the pre-fix version of the report. I’ve fixed a ton of those issues.)

When solving the issues I saw on my public site, I relied on the local HTML validator of the Web Developer Firefox extension to help me make sure I was solving the issue. This extension is packed with helpful tools, but today, the Validate Local HTML tool was invaluable, letting me test local dev changes without publishing.

Towards the end of applying my fixes, I also utilized the WAVE (Web Accessibility Evaluation Tool) provided by the WebAIM organization. The presentation of structured content and inline overlays of problem areas was helpful—an example report using one of the test pages from the course.

With most of the accessibility issues resolved, I still had some recommended tools I wanted to try.

Lighthouse is a popular web performance tool. It does include some automated accessibility checks but is way more focused on performance. There are browser extensions for Lighthouse, but you can also run it from the web.

I used some Lighthouse feedback to make some slight changes to my image preloads to ultimately help with Largest Contentful Paint (LCP) timings and drawing the page faster.

What also caught my eye was some Lighthouse CI tools. These can slip into your CI toolchain to generate reports, and enforce performance requirements. I did some experiments but would need more time to work correctly. There is even a server you can run so you might track the status of various performance metrics over time. This could be really powerful for a site of importance, but it is well outside my work scope this week.

In addition to Lighthouse CI, I also took note of Pa11y and its own Dashboard tools which seem to solve similar automated measurements over time.

More Resources

WebAIM (web accessibility in mind) has a wonderful collection of articles and resources that can help provide curated and more accessible guidance.
Accessibility Weekly Newsletter is a weekly dose of web accessibility to help you bring it into your everyday work. Delivered to your inbox each Monday, curated by David A. Kennedy.
The W3C Web Accessibility Initiative (WAI) develops standards and support materials to help you understand and implement accessibility. This is a general index with lots of information.
The Web Content Accessibility Guidelines (WCAG) docs can be a little dense but helpful to reference if you are debating different approaches.

Notes

VoiceOver will often read the file names, so if you can avoid gibberish names like 20e47595573f720f.jpg, please do.
Generally speaking accessibility conformance is measured and labeled with A, AA, and AAA; and you may see tools like color contrast saying A level conformance is met but AA is not.
I think automation such as CI running these tools and inline component testing of accessibility will be important if a team wants to maintain an accessible site over time. I’d similarly recommend bi-yearly (or more often) manual audits to identify improvement opportunities.

Future Enhancements

GitHub and other sites provide this cool detection of tab and immediately show a Skip to Content link at the top, and when you press Enter, it jumps to the content. I would love to add that to my blog.
Many web apps have aligned on showing keyboard shortcuts using ?. I want to consider doing that for future web apps and maybe even search tools for the blog.
I’ve started moving my blog videos into a simple S3 bucket store. I want to figure out a way to provide text transcripts for them.

Every journey begins with a small step. I enjoyed the opportunity to skill up with accessibility, and hope to continue to apply it to future work.

How to Use a Modern Version of Hugo on Render's Static Site Service

mike@mikezornek.com (Mike Zornek) — Thu, 17 Apr 2025 11:03:15 -0400

I host this site at Render.com. Specifically, I use Render’s Static Site product. It’s a good product and free for most usage. It features an auto-configured SSL certificate, global CDN, pull request previews, and many other nice things. I’m also paying Render to host some Elixir things and enjoy the simplicity of fewer things to manage

When you read the docs, Render provides instructions on what to do if you are using Hugo to build your static site. Unfortunately, their version of Hugo is locked and a bit dated as I type this. (I observed version 0.124.0 when the current version of Hugo is 1.46.5.) Some other static allow you to set a HUGO_VERSION environment variable, but sadly Render does not support this.

Render allows you to supply a custom build command, and I’ve taken the opportunity to install an updated version of Hugo per deployment so I can keep it current. Here is the script and some other notes to keep in mind.

Using a custom build command

You can read more official docs about the build command, but in short, you set it up in the Settings for your site. Instead of a single command, you can point it to a build shell script from your project’s repo.

My build script looks like this:

#!/usr/bin/env bash

# This script is used by Render to build the app for production deployment.

# set up an exit on error
set -o errexit

# Save the initial directory
ORIGINAL_DIR="$PWD"

# Install npm dependencies
echo "Installing npm dependencies..."
npm install --verbose

# Install specific version of Hugo
HUGO_VERSION="0.145.0"  # Change this to your required version
echo "Installing Hugo ${HUGO_VERSION}..."

# Create directory for Hugo download and installation
mkdir -p "${HOME}/bin"
mkdir -p /tmp/hugo
cd /tmp/hugo

# Download and install specific Hugo version
wget -q https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_extended_${HUGO_VERSION}_Linux-64bit.tar.gz
tar -xzf hugo_extended_${HUGO_VERSION}_Linux-64bit.tar.gz

# Move Hugo to a directory you have permission for
mv hugo "${HOME}/bin/"

# Add the bin directory to PATH
export PATH="${HOME}/bin:${PATH}"

# Verify installation
hugo version

# Return to project directory
cd "$ORIGINAL_DIR"

# Now you can add your Hugo build commands here
hugo --logLevel info

In addition to installing Hugo, I also install some npm packages, including Tailwind and the Tailwind Typography plugin, which I am using for my Hugo template HTML. One thing to keep in mind here is that Render does honor and expect a NODE_VERSION inside your environment settings to hint what version of node to use. This static site was defaulting to a pretty old version of node when I started without a NODE_VERSION environment variable, and that seems to be based on when the static site service was initialized.

I do a bit of extra logging to help me debug, but overall, this script is pretty straightforward. Make sure to grant execution permissions with chmod a+x build.sh to the shell script when composing it.

Inefficiencies

Installing Hugo (and node things) for every deployment is excessive and will be charged against my pipeline minutes, but for the simple needs of this site, which is published a few times a month I doubt it will add up to anything much. If you want to optimize this, consider Dockerizing the deployment and perhaps even assembling the static content in a continuous integration system like GitHub Actions. (I was planning on that at first, but this build command approach was more straightforward for now.)

How I Got Rid of My Google-Hosted Web Fonts

mike@mikezornek.com (Mike Zornek) — Tue, 15 Apr 2025 08:19:13 -0400

Over the last few weeks, I’ve been doing some infrastructure updates to the website, and one of those changes was to drop the use of Google’s linked web fonts and instead host custom fonts from my own server in the spirit of improving the privacy of my site visitors.

Here is how I did it and some of the problems I ran into.

Picking your font

The first custom font I had in mind was Ubuntu, a bold sans-serif font that I like for my name in the header. You can see samples of this on Google’s site, but to download it, I take advantage of the google-webfont-helper site, which lets me quickly customize the exact styles I am interested in using and offers me a list of various CSS methods of use. I use the more modern CSS approach, as seen in the following snippet.

/* ubuntu-regular - latin */
@font-face {
  font-display: swap; /* Check https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face/font-display for other options. */
  font-family: "Ubuntu";
  font-style: normal;
  font-weight: 400;
  src: url("../fonts/ubuntu-v20-latin-regular.woff2") format("woff2"); /* Chrome 36+, Opera 23+, Firefox 39+, Safari 12+, iOS 10+ */
}

/* ubuntu-700 - latin */
@font-face {
  font-display: swap; /* Check https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face/font-display for other options. */
  font-family: "Ubuntu";
  font-style: normal;
  font-weight: 700;
  src: url("../fonts/ubuntu-v20-latin-700.woff2") format("woff2"); /* Chrome 36+, Opera 23+, Firefox 39+, Safari 12+, iOS 10+ */
}

Source: assets/css/main.css

Aside: I still need to add a proper license display for this font usage. That is still forthcoming.

Using your font with Tailwind

The other notable infrastructure update was to make it so I could use Tailwind within my Hugo templates. To reference my font, I use the following Tailwind utility class:

<h1 class="font-[Ubuntu] text-6xl font-bold">{{ site.Title }}</h1>

If you want to use a font more broadly, I’d recommend editing Tailwind configuration so you can express fonts with better abstractions at call sites, but for this one-off header, this is fine.

Avoiding Flash of Unstyled Content (FOUC)

After deploying my new self-hosted fonts, I observed flashes of unstyled content. Specifically, Safari would display the header copy in a serif font and then swap it into Ubuntu. Both Safari and Firefox would flash the new header background texture image as I clicked from page to page.

I did a little reading and landed on the following solution, which has me use <link> elements included in my <head> to help hint to the web rendering systems more early in the drawing process that it will need these resources before the first paint.

<link
  rel="preload"
  href="/fonts/ubuntu-v20-latin-700.woff2"
  as="font"
  type="font/woff2"
  crossorigin
>
<link
  rel="preload"
  href="/fonts/ubuntu-v20-latin-regular.woff2"
  as="font"
  type="font/woff2"
  crossorigin
>
<link rel="preload" href="/images/dark-mosaic.png" as="image">

I think these are working well.

The font preload explicitly needs crossorigin for CORS things, but the image did not, which I find interesting.

I’ll probably be doing more with my fonts and the overall design of the site in the coming weeks, but this was a good nugget of progress.

Resources

If you want to avoid hosting a font, consider limiting your options to more likely supported options from the OS. Dreamhost has a blog post outlining some good choices for each family style.
If you want to learn more about fonts (and basic design), I highly recommend The Non-Designer’s Design Book by Robin P. Williams. Its teachings stand the test of time.
I mentioned background textures, and if you are looking for some, check out this helpful gallery.

Early Svelte Thoughts

mike@mikezornek.com (Mike Zornek) — Sat, 22 Jul 2023 17:25:51 -0400

After more than five years of giving my full attention to Elixir, Phoenix, and LiveView as the primary toolkit I use to build web apps, over the last few weeks, I’ve started to sample some other tech stacks, with an initial focus on Svelte and SvelteKit. Here are some early thoughts.

Why the move?

This move comes from an ongoing, uneasy feeling that the current LiveView ecosystem lacks the significant and diverse set of choices for libraries that I find myself looking for to help me stand up new UI ideas quickly. LiveView will allow you to build almost anything; you just have to make it yourself.

I do observe improvements to the core LiveView technologies that may help improve community offerings in the future, but for now, this is how I see it.

Additionally, there is a particular set of user interactions that I am interested in providing in my user experiences (file uploads, drag and drop, rich animations) that, while possible in LiveView, none-the-less require JavaScript – and then I ask myself why not just work in that environment from the beginning?

I also feel like the WebSocket nature of LiveView has some unfortunate tradeoffs regarding offline or flaky network/phone environments. It hasn’t been a significant blocker in my production work, but it is always part of the conversation. If I were to build something with a more common mobile web experience target, I’d be worried about the WebSocket tradeoff.

To be clear, Elixir and Phoenix, in general, I’m still very positive about. Suppose I were to use a different frontend technology. In that case, I suspect I’d still use an Elixir/Phoenix project to provide a GraphQL API, manage jobs, push notifications, emails, and all the other platform needs. I might even still use LiveView for an admin area.

Why Svelte?

Similar to an approach that led me to Elixir many years ago, I took some time to review the current state of web frontend technologies. If I were to follow the herd I’d probably pick React and/or Next.js, but there was just something special about Svelte for me.

A few notable things:

First off, Svelte is a component system and SvelteKit is a web framework.
Svelte components are compiled and executed in the browser space using standard JavaScript. There is no typical React-like runtime, and the code generated is much leaner than the historic SPA JavaScript bundle sizes.
You can do server-side rendering to provide SEO-friendly HTML for non-authenticated pages.
The style of building Svelte components is light and approachable.
There are significant animation tools within Svelte to provide a dynamic presentation of UI elements.
The Svelte project and community seem lively and are not overpowered by an individual corporation.
The technology is a little on the younger side, which does hamper the community library interest that kicked off this search, but I’m seeing enough and seeing good momentum that I think I’ll be happy.
The store model for reactive data seems well structured.
There was a great set of interactive tutorials that helped me get stated. Afterwards I also worked through the Fireship course (though I’m not sure I’d recommend it).

A few negative tradeoffs and concerns on my mind:

Generally speaking, I do not love the JavaScript ecosystem. I’ve tried to avoid it as much as possible over the last 15+ years (avoiding it with ease during my Apple time and avoiding it a lot during my Elixir time).
Stale npm projects can get dangerous quickly as modules go missing or dependency issues are introduced. Even working on the just released Fireship course, I hit issues trying to deploy; though this was more an experimental Firebase deploy thing than a Svelte thing; but it speaks to my worries of npm in general.
The lack of testing tools in the standard SvelteKit project template is a little worrisome.

My next steps are to wireframe a new project idea I’ve been pondering and then get hacking to see how I like it. You can only do so many tutorials.

Learn one new language a year.

This Svelte experiment is also good for my consulting/career. It’s been harder to find regular consulting work, and expanding my technical skillset might lead to a few more opportunities.

I’ve always promoted the idea of learning one new language a year, even when you will not be applying them right away. In 2021 it was Rust, and in 2022 it was event sourcing. It feels like 2023 is the year of Svelte.

Is WebKit Sabotaging the Future of the Open Web?

mike@mikezornek.com (Mike Zornek) — Mon, 06 Jul 2020 17:10:19 -0400

This didn’t get much press at the time, but during WWDC the WebKit team listed a bunch of web technologies they will apparently not be implementing in the name of privacy.

Fingerprinting involves measuring the uniqueness of static device configuration (e.g. built-in hardware), dynamic device or browser configuration (e.g. user settings or installed peripherals), and user browsing data (e.g. checking which sites the user is logged in to, so-called login fingerprinting).

WebKit’s first line of defense against fingerprinting is to not implement web features which increase fingerprintability and offer no safe way to protect the user. Here are some examples of features we have decided to not implement in part due to fingerprinting concerns:

Web Bluetooth

Web MIDI API

Magnetometer API

Web NFC API

Device Memory API

Network Information API

Battery Status API

Ambient Light Sensor

HDCP Policy Check extension for EME

Proximity Sensor

WebHID

Serial API

Web USB

Geolocation Sensor (background geolocation)

User Idle Detection

Just to be clear, I am a privacy advocate. I use DuckDuckGo. I use Firefox. I block ads. I encrypt my DNS lookups. I’m building a privacy-focused tool for meetups. And with all that said, this worries me.

Right now, many mobile developers would argue that for a rich user experience you need to build a native app and I would agree, at least I would as of today.

But if I’m reading the tea leaves right, and history is a model to follow, what requires “native device” code today will be possible in the web browser of the future. WebAssembly shows great early promise in providing rich cross-platform code opportunities. If you are a 1Password user like me, you are probably already enjoying some WebAssembly today.

However, to build rich user experiences on a mobile device using WebAssembly or inside a normal web app requires access to the sensors and systems of that device. With this collective blocking of access (along with the lack of side loading options on iOS and the ban of non-WebKit rendering in App Store apps) Apple has positioned their own native and financial interests over the favor of an open web.

Why can’t the WebKit developer energy be spent on building these great new APIs and connect them with user empowering privacy tools. A great example of what I mean is website location tracking. If a website wants access you your location (for say driving directions) you can grant it access. I don’t understand why a similar approach could not be applied for things like Web Bluetooth access or Proximity sensor access.

I applaud many of the privacy decisions the WebKit team has made over the past couple of years, but this one feels wrong.

When I was learning to program in the late 90s we had another big platform vendor who sabotaged the web browser market for their own interests and I do not want a repeat.

Website Revamp

mike@mikezornek.com (Mike Zornek) — Tue, 17 Dec 2019 14:01:51 -0500

At the end of November I took a few days and revamped this site. Let me know if you spot any issues or typos. Thanks!

What’s New

I rebuilt, from scratch, the Hugo theme code the site uses, wanting to own the site in both design as well as content.

I added a small bit of color and branding to the main header navigation. I’m still big on simple page designs but also feel like returning to a blog post after being here before should have some sense of branding / nostalgia.

New section, For Hire. To date I’ve hosted a simple company site at zornlabs.com. It was never much but when considering the idea of building out a project portfolio there it just felt like I was spreading myself too thin across multiple sites. I think for now it’s just easier and more productive to focus on a single site to sell me and my services better.

New section, Projects. Wanting to sell my consulting services, it’s important to have a portfolio of some kind and the new Project section serves to do that. For now each project has a short description and accompany video file. I hope to expand it more in the future with some open source efforts.

Events section renamed Talks. Still not sure if this is the best name but it does describe the goal of the section, to help document and list the various event and conference talks I’ve done. The fact it additionally list conferences I’m attending is a little verbose, but does help color what I’m interested in and excited about.

The site is now open source, available on GitHub for all to check out.

New Year, New Site

mike@mikezornek.com (Mike Zornek) — Tue, 01 Jan 2019 19:51:21 -0500

Happy New Year everyone! Hope everyone had a nice break and is recharged for the new year.

While most of my own break was quiet I did have one side project, rebuilding this website. It’s now hosted through a toolchain that includes Hugo, a static site generator written in Go, GitHub, CircleCI and Linode, replacing the previous WordPress setup.

I have nothing against WordPress, but it was overkill for my own needs and I generally like the idea of keeping my server lean, and a static site makes that easier.

The setup is very similar to my previous build of the PhillyCocoa website. The theme is not custom like PhillyCocoa, but a hack job on the Pickles theme. It’ll do for now but is as a good a base as any.

If you utilize the RSS feed for this site you might want to resubscribe. I’ve setup some redirects for old feed paths but other formats that WordPress provided (like ATOM) are not currently supported.

Similarly I’ve updated my Micro.Blog to use my own domain now, so its RSS feed is updated as well.

Feels good to check this project off the list. Hopefully it will encourage some more writing in the future. Stay tuned.

Closing Thoughts on Big Nerd Ranch’s Front End Web Class

mike@mikezornek.com (Mike Zornek) — Thu, 13 Oct 2016 01:48:24 +0000

I posted a few thoughts while I was attending the Front End Web class last week and I figured I’d put a cap on it with some final thoughts.

Disclaimer: If you happen to find this post and don’t know, I do in fact work for Big Nerd Ranch, so yes I’m partial but these are still my honest opinions.

Who is this class for?

Like other BNR books and classes, there is an expectation of some experience. You don’t need to be an expert by any means for this class but you should be comfortable with the basics of web design, hosting and how the web works. If you are looking for these beginner skills I’d recommend Code School and/or Code Academy.

With the basics taken care of, this class provides an accelerated but thorough tour of modern web development and the toolchains that you need to know. The class is great for people like myself, who have a history of web development but have been out of the game for a few years or mostly focused on the backend systems. Others who would find value include those who are looking to jumpstart a new web skill set for a new job or project.

Having a full week to escape the distractions of work and personal obligations really enables you to focus on the class at hand. Combine this with guided lectures and an experienced instructor to answer questions and discuss patterns, really elevates the value to “priceless”.

The Syllabus

The table of contents titles don’t really do justice to the details of each chapter. In total we build four separate projects:

The first had us work with HTML5, CSS and JavaScript to do a moderately complex layout of a slideshow like page that included animations, responsive layout and modern markup techniques.
The second project was a Coffee Order system the helped us use HTML5 forms, Bootstrap styles, and JavaScript to communicate with a backend via AJAX.
The third project was a chat app, that utilized web sockets. For this app we not only built the front end but the backend too, in Node.js.
The fourth and final project was an EmberJS app that would have us catalog monster sightings. Ember is a big framework but I think the book does a fair introduction. We got to work with a relationship of models, and executed all the big features.

I thought the chapter and project progression went really well. There are some who might prefer to end with Angular or React instead of Ember but the good thing to know is the early class concepts give you a great JavaScript foundation to build on so you’ll be empowered to experiment with all of those projects and more over time.

That is a core value of Big Nerd Ranch classes that I really agree with. They teach you from the bottom up so you can understand how things work and not just how to assemble/configure things.

The Extras

There is lots of open lab time at night. You are encouraged to bring a side project to work on. While I did make some progress on my own project, an Ember Wiki project (I have some basic models and forms working, all backed up my a Firebase persistence layer), I did have to dedicate some lab time to the book itself to make sure I kept up.

In the afternoons we’d have time for a walk around the resort and on some of the days we even arranged for a shuttle van to take us to some of the exhibits, like the Birds of Prey and the Butterfly Center. Considering how focused we are during the class, these excursions are very welcome and a great way to clear your head and get a second wind.

Final Thoughts

If you want to learn a new technology, in this case Front End Web Development, and in particular if there is a time-sensitive nature to your needs it’s hard to imagine a better environment than a Big Nerd Ranch class. The ticket price does include lodging and food for the week so keep that in mind when shopping around or putting together a formal company request. If you have any questions, feel free to contact training support. They’ll be happy to help you out.

Greetings, from the Ranch

mike@mikezornek.com (Mike Zornek) — Mon, 03 Oct 2016 02:08:59 +0000

One of the great perks of working at Big Nerd Ranch is that you are allowed to take one Big Nerd Ranch class a year. This week I’m taking the Front End Web class, and am really looking forward to it.

At nights we are encouraged to work on a side project to help practice what we are learning in the day. I think I’m going to work on a wiki app — with a few touches that I myself have an itch for, drag and drop image uploads, code syntax coloring, and more.

I’ll check in later through the week. Wish me luck.

Philly CocoaHeads Website Relaunch Project

mike@mikezornek.com (Mike Zornek) — Sun, 22 Feb 2015 23:37:27 +0000

I haven’t had an active side project in the last few months. When asked I would tell people looking for a new job was my side project. Now that I have that new job search (and my Girl Develop It class behind me it’s time to kick something off; we’re going to rebuild the Philly CocoaHeads website!

When I took over the local chapter of CocoaHeads here in Philly (back in 2010 or so) the previous organizer had a Ruby/Markdown publish system setup. It was kind of neat but involved a lot of setup on the client box to get up and running. I had a few people posting to the site so rather than set up that system on each individual’s box I opted for WordPress. The WordPress site has done ok for us but we’ve been growing a ton and doing a lot more over the last year (workshops, video capture of meeting presentations). I’d love to start to centralize things like keeping track of our members and our money, overall there is a ton that could be automated and it’s time to make it happen.

I don’t want to do this alone and I also would love to start documenting the project as it unfolds. To get started we have a brainstorm session scheduled during Side Project Saturday. If you want to participate please consider stopping by. If you can’t stop by, but want to participate, let me know and maybe we can setup a Google Hangout call-in option. To capture notes I’m going to use Trello. The board is live and open to the public. (You will need to login with a Trello account to edit.) Feel free to start to document your ideas today.

Early Ember.js Thoughts

mike@mikezornek.com (Mike Zornek) — Tue, 05 Feb 2013 17:03:16 +0000

Over the last three weeks, I’ve been slowly picking up Ember.js while helping some colleagues with a project. It’s pretty interesting tech and I’d like to share some early thoughts.

What is Ember?

To be frank, I don’t think the Ember homepage does a very good job of explaining Ember. It features terms like “less code” and “developer ergonomics,” which are too much like “marketing speak” for me.

How I view Ember. Normally with a web app, you (as a user) will go page to page, sometimes viewing data and then sometimes editing data with forms. That’s what I’ll call a form-based web app. Sometimes you might want a bit of AJAX in these form-based web apps and, to get that, you’ll typically grab a DOM element and manually shove in a bunch of jQuery when needed, including direct commands and event callbacks. This process can work, but the more AJAX and client side stuff you add, the messier you can make things.

Then there is a class of web apps which work as one-page apps, where all interaction and DOM changes happen on the fly, without moving from page to page. Data is sent to and requested from the server in the background. Think of how Gmail and Trello work.

For me, Ember.js is all about giving you the toolchain to provide those types of dynamic, one-page web app experiences. Ember.js is a full stack, client-side, JavaScript-based MVC framework. The main objects you’ll work with client-side in the browser include:

Routers, which match the requested URL to controllers. They also ensure that the client URL is updated to allow the user to bookmark the different states of your app.
Models, to define your business nouns and store/retrieve user data.
Controllers, which handle actions and pass model data to the views.
Views to connect user events like clicks and taps to controller actions.
Templates to describe the HTML on screen.

Some Notable Features

Bindings

If you’ve done AJAX work before, you might recognize that knowing what to update in the DOM can be a nightmare as the app state changes on a given page. Ember is particularly good at dealing with this, and as you build your HTML templates, the substitution hashes like {{ name }} for a person’s name not only are substituted for the real value on the first render, but everything is always kept up-to-date with an internal bindings system. This, combined with calculated attributes, really takes a lot of stress off the developer, in terms of keeping the app state in sync with the UI state.

Persistence

For actually persisting the data, there is the ember-data project which will let you connect and map your client-side Ember models to REST endpoints. If you are using Rails, there are a bunch of gems that can really help to simplify this while providing all the serialization and API endpoints you’ll need. For more info, see this article.

Sharp Edges

As of this writing, Ember itself is version 1.0.0-pre-4 and ember-data is officially considered alpha quality. There is an upcoming Ember Camp, which hopes to see continued progress towards an official 1.0 release. Keep an eye on the Ember blog for more info. I do believe things have settled down to a point where there is value for people who want to get started with Ember and get their hands dirty. As to “production ready” — well, that will greatly depend on the needs of your application and your comfort with working around some sharp edges.

Getting Started

If you’d like to get started with Ember, in addition to the main website, which has some nice and ever-improving documentation, I’d also recommend:

PeepCode’s Fire Up Ember – Brand new, up-to-date, and very focused on the Ember stack. Well worth the $12.
An Ember.js tutorial by Trek – Walked through this myself when I got started. It helped a lot.
Brian Cardarella’s Building an Ember app with RailsAPI – Great walkthrough about starting an Ember app that will use Rails for persistence.

If you are in Philly, also consider stopping by the local Ember Meetup.

Researching New Web Tools

mike@mikezornek.com (Mike Zornek) — Fri, 31 Aug 2012 03:12:52 +0000

I’ve been spec’ing out this app idea off and on for a few months. At first I was going to do it on the Mac, but, as time passed, I decided to make it a web app in the newer style instead. Not a “present form, hit submit, view results” kind of thing, but something that is always saving and receiving messages from the server — very dynamic.

I’m actually blessed that there are a number of great web tools, libraries, and frameworks to choose from these days. One great overview I read last night was Rich JavaScript Applications – the Seven Frameworks by Steven Sanderson. It does a great job listing and categorizing some of the more popular choices out there. New to me on the list was Meteor, and I consider its video a must-see.

I’m still getting my head around many of these things. My general battle plan is to continue reading and playing with the example code of my CoffeeScript book (which also has some basic jQuery and NodeJS stuff), and then work through some of the various implementations of TodoMVC to see what tech speaks to me.

TodoMVC

TodoMVC is a project that offers the same Todo application implemented using MV* concepts in most of the popular JavaScript MV* frameworks of today. These frameworks include Backbone, Ember, AngularJS, and Spine, to name a few. TodoMVC offers a great way to see how different stacks approach the same problem.

Other tools that are relevant to my cause and look promising include:

Ace

Ace is a standalone code editor written in JavaScript. Our goal is to create a web-based code editor that matches and extends the features, usability, and performance of existing native editors such as TextMate, Vim, or Eclipse. It can be easily embedded in any web page and JavaScript application. Ace is developed as the primary editor for Cloud9 IDE and the successor of the Mozilla Skywriter (Bespin) Project.

ShareJS

ShareJS is an Operational Transform library for NodeJS & browsers. It lets you easily do live concurrent editing in your app.

While I personally have a lot of Rails experience, I’m not going to shy away from NodeJS and other solutions. I almost welcome the opportunity to try something new these days. I’m also very excited to see that the NodePhilly group has gotten off the ground — I hope to make the next meeting in September.