DEV Community: Jason Joseph Nathan

The 5 Best Downloaders for Videos, Music & Images (No Browser)

Jason Joseph Nathan — Thu, 11 Sep 2025 19:05:26 +0000

Remember downloading at 4KB/sec? These five modern tools are faster and don’t need a browser. Perfect for terminal nerds and nostalgia junkies alike.

Source

You Can Blog from Your Local WordPress Site on iPhone. Here’s How.

Jason Joseph Nathan — Sun, 18 May 2025 13:58:55 +0000

Access your local WordPress site from your iPhone using ZeroTier or Tailscale. Blog from anywhere securely, privately & with no cloud in sight.
Source

The Invisible CDN We Built for Display Pics

Jason Joseph Nathan — Wed, 23 Apr 2025 06:35:14 +0000

We built an invisible CDN using Nginx and PHP with no exposed URLs, zero strain, and avatars that never go stale.

Source

The Editorial Engine: A Technologist’s Pilgrimage

Jason Joseph Nathan — Wed, 16 Apr 2025 05:44:35 +0000

What if the reason you’re not writing isn’t discipline, but design? A technologist reflects on blogging and where it all begins.

Source

Neo Should’ve Picked the Blue Pill

Jason Joseph Nathan — Wed, 09 Apr 2025 12:28:55 +0000

A Sci-Fi fable of fat, fire & forgotten biology, where ketosis outshines carb culture & the machines that plugged into the wrong end.

Source

We Broke the Web. Can WebO+ Fix It?

Jason Joseph Nathan — Tue, 18 Mar 2025 06:19:49 +0000

Let's be honest. The Web has gone through so many self-imposed revolutions, it looks a lot more like a badly managed startup. Pivoting. Perpetually. Forever rewriting its mission statement. But as a side-effect, it tends to generate buzzwords. A ton of them. So here's another one:

WebO+

But let’s start at the beginning. We had Web1.0 - which wasn’t a term that was ever actually coined - but was known as the read-only web. Then Web2.0 came with all its interactivity and API-driven web apps. And finally, we met Web3. What’s next?

I’d say that after 25 years of (re)inventing complexity, we don’t need Web4. We just need to fix Web2.0. But before we talk about the fix, let’s talk about how we broke it.

Full article below. Originally posted on geekist.co. Do subscribe for updates!

The Web. What Went Wrong?

It began as a beautifully simple thing. Somewhere out there, there was a computer that held a ton of webpages. And then, there were tons of computers - with tons of webpages - ready to serve any one who requested them.

You would pick your favorite browser application (probably Netscape) and fire it up. And then you’d be greeted with AltaVista (depending on the year, it might even be Yahoo) and then you’d type in a search and Boom!

But it wasn’t just a tool. It was a cultural moment. This old Yahoo! ad captures the vibe perfectly.

This was one of my absolute favourites ads at the time!

But something wasn’t right. The web was… boring. Sure, you could read stuff. But why couldn’t we have the same interactivity we had in games? Why couldn’t the Web feel alive?

And why not? That’s when Web2.0 was born.

Web2.0: The Social & API-Driven Web (Mid-2000s – 2020s)

Suddenly, web pages transformed from regular Wikipedia looking articles to full blown Web Applications.

The term Web Application actually felt triumphant. No serious programmer at the time thought much about Web Developers. No one would dare call us Engineers. Very few even wanted to call us Programmers. You could almost hear them mutter under their breath:

“What? JavaScript? PHP? Ewww…”

Many thought we were “Java” fan boys and girls. Meanwhile, some of us made their salaries look cute.

Then came the Buzzword Bonanza™ - AJAX, JSONP, OAuth. Suddenly, the FrontEnd Engineer (oops, developer) was born. And just like that, frameworks exploded. Your Yahoo! wasn’t Yahoo anymore - literally.

You could suddenly do more. You could talk! Err… chat! And guess what else?

You could totally click on a Button and you wouldn’t have to wait a week for the page to reload!

And it didn’t stop there. Buttons changed color, shapes moved, hover effects responded before you even clicked. The web came alive. Stuff glowed. Things got bolder. Move your mouse, and… something popped out!

Oh, and in case you were wondering, yes, that’s totally where popups came from. At least until we invented pop-up blockers to fight back.

It was a game changer: Skeuomorphic design, Zoomable User Interfaces (remember this?) and of course, the rise of Social Media.

The web became Live. Fun. Interactive.

But beyond the flashy buttons, glowing elements and real-time interactions, something bigger was happening…

Browsers weren’t just rendering cool effects; they were offloading serious computation from our servers to our users’ machines. Instead of relying on expensive, multi-core, memory-filled servers, we realized that every single user already had compute power at their fingertips.

We went from the browser rendering pages to the browser rendering entire applications, full-blown, desktop-grade software. The browser became the new runtime; an OS inside an OS, shouldering the burden once meant for the backend.

At this point, people were finally calling us Engineers. Well… no. We were calling ourselves Engineers. And loudly. And no one was arguing with us.

It was a brilliant move.

Until it wasn’t.

SEO took a NoseDive

Turns out, search engines didn’t sign up for this full-stack revolution. Google could read JavaScript, sure. But understand it? Not so much. Beyond that, performance tanked. I’m sure you’re saying, “But wait. No it didn’t!”. It did, but you probably didn’t feel it because we were graciously met with so much more compute power, much more than we ever did before

Developers were shipping megabytes of JavaScript just to render something as simple as a list. What once took a single HTML file now required hydration, client-side loops, and API calls. It suddenly took tons of JS to make anything functional. In turn, that created new problems. Latency suffered. We had to figure out how to pre-render out static pages (remember PhantomJS anybody?).

Then came React.

Then came the first hydration issues.

Then came Hydra. Cut off one head, two shall take its place… Sorry. Hydration Hell.

And if that wasn’t enough, something even worse was happening behind the scenes. While we were drowning in hydration hell, large organisations were quietly harvesting our data - and selling it. How? They made shiny cool things we could use for free and made us accept terms no one bothered to read.

The cracks weren’t just showing, they were splitting wide open. The web had become a bloated, exploitative mess, and no one knew where to start fixing it.. We needed something new…

Web3. The Decentralized, Crypto-Powered Web (2020s – Now)

Notice something? We got cooler. We dropped the .0. Just Web3. Clean. Minimalist. Sleek.

Oh dear God, no. Not even close.

At least we got new buzzwords! Blockchain. Crypto. Smart Contracts. Decentralization. Tokens. Mining. NFTs. You get the idea. Web3 came in hot, promising to fix the internet by removing central control and letting users own their data. And in many ways, it delivered - for finance, supply chains, trustless transactions and so much more.

But that didn’t actually fix any of our Web2.0 architectural problems, no sir. In fact, people started slapping blockchain on everything. Suddenly, blogs needed tokens, APIs required smart contracts and even basic web apps were being rebuilt with decentralized infrastructure. So instead, it just added more to account for.

At this point, we had truly outdone ourselves. In pushing the boundaries of technology, we didn’t just innovate,we over-engineered everything. And in the process, we gave an old word a brand-new meaning:

Overkill.

But. Finally. After years of over-complication, we hit The Great Reset.

WebO+. The ultimate Rollback-olution™ (2020s – Now)

It’s absurd how we’ve come full circle. We began with server-side rendering because that’s all we had. Then JavaScript evolved, and we pushed more work onto the client. Then came Internet Explorer, which we shall not speak of. Eventually, we decided that sending full HTML pages was too expensive - so we switched to sending JSON. Then, JSON was too big, so we optimized it with better compression. Then, in our pursuit of the ‘pristine’ server, we decided it should only speak one language - JSON (or protobuf) - while the client handled the heavy lifting.

Then reality struck. We still needed server-side rendering for SEO, accessibility and performance. But instead of admitting the mistake, we Frankenstein’d a solution - client-based SSR. And after years of jumping through hoops, we arrived back where we started: Server-side Rendering.

The simple truth hit us: The original web had it right all along. We didn’t need a new paradigm. We needed to stop over-engineering everything.

WebO+ isn’t about going backwards - it’s about correcting 25 years of misdirection. It takes the best parts of Web1, Web2, and Web3 and cuts out the nonsense.

Feature	Web1	Web2	Web3	WebO+
Server-side HTML	Yes	Partial	No	Yes
UI Rendering APIs	No	Yes	Yes	Optional
SEO-Friendly	Yes	Partial	Partial	Yes
Perf (Page Load)	Yes	Partial	Heavy	Yes
Client JS	No	Yes	Yes (dApps)	Optional

WebO+ is what Web1 would have been, if we had today’s hardware, compression, and smarter rendering.

What it does right.

Now this is assuming you still need a server to make API calls and you’re not generating static pages and serving them out of CDN.

For starters, we’re back to the early 2000s where server-rendered, SEO-friendly pagination still matters, even though client-side tricks like pull-to-refresh make browsing smoother.

But now, servers are more powerful, and compression is faster than ever. Instead of juggling JSON responses and complex client-side loops, the server just sends fully rendered HTML, and the browser drops it straight into the DOM. No extra processing, no unnecessary hydration, just fast, direct rendering.

Yes, you can still use JS/TS on the backend, and yes, you can still reuse the same logic for both server-side and client-side rendering. But some tasks like click handlers and state changes must stay client-side.

The difference? You don’t need to structure two separate component types anymore. Just sprinkle in client-side functionality where needed.

Some frameworks, like Svelte, go further by allowing client-side logic within the same file, making the distinction seamless.

And it’s not just Svelte. SSR is back across the board. Frameworks like Laravel, Next, Nuxt and SvelteKit have brought server rendering back into the mainstream, making it practical again: lean servers, fully rendered pages, instant loads.

React now embraces SSR with Next.js and React Server Components (RSC), though hydration issues still make it more complex than traditional SSR.

A Small Aside, What Inspired this Article?

You see, I saw a video called “Next.js Best Practices You can’t ignore” and the first thing the author said was something along the lines of “Dude, are you using Page Router? Stop. Use App Router.” but he didn’t do much of a job elaborating. So curiously, I asked ChatGPT about it and this is the gist of what I got back:

“Oh, App Router is like how we built websites in the late 90s and early 2000s.”

And then. Something inside me broke.

So I forced my partner to sit down and listen to me rant. I went on and on and finally ended with telling her what I would say to Devs at the time:

It doesn’t matter if the server-side code is pristine gold if your client-side code looks like Medusa just woke up from a freggin’ hangover.

She laughs. That’s something I guess. And the ranting made me feel better so before I go, there are some more things that need to be said.

Frontend Development pushed browsers so damn far that they became full-fledged operating systems. _Chromebook anyone?_

It pushed GPUs to their limits. It pushed JS engines to the point where V8 became so powerful that it didn’t just optimize web performance - it gave birth to entire server-side ecosystems like Node.js & Deno. (Yep. The same dude started both)

Meanwhile, server-side computing kept getting stronger. But most of these BFFs were just sitting there, idling. So the push came from the frontend: “Wake up, server. We need you to do more.”

We’re finally waking up to the fact that frontend wasn’t supposed to be doing all the heavy lifting.

Finally. We are shifting back. So I’d say…

Goodbye hydration hell.
Goodbye unnecessary client-side API calls.
Goodbye shipping 5MB of JavaScript just to render a list.

And then I'll say…

Welcome back, server-rendered HTML.
Welcome back, pre-rendered content.
Welcome back universal UIs

🔥 Welcome to WebO+.

I can't believe it took me 5 years to stumble upon such a good read. :)

Jason Joseph Nathan — Mon, 17 Mar 2025 05:09:47 +0000

Node.js Under The Hood #7 - The new V8

Lucas Santos ・ Jan 5 '20

#node #javascript #v8

Why Your Tech Stack is Overrated (And What Actually Matters)

Jason Joseph Nathan — Thu, 13 Mar 2025 17:53:10 +0000

The Debate That Didn’t Matter

In 2017, everyone - including yours truly - was passionately caught up debating the virtues of React Native versus going fully Native. I even penned a fiery rant about it here, convinced I'd cracked the code myself on app development.

But looking back now, it feels like we were totally arguing about who had the cooler shoes in primary school which as fun as it was at the time, was ultimately meaningless. The truth is, it wasn't frameworks or flashy tech that determined success; it was something far more mundane.

Real success hinged on fundamentals like choosing an architecture that scales, keeping logic decoupled and resisting those tempting short-term optimisations that always seem clever until you're buried under technical debt months later.

Turns out, frameworks come and go, but good architecture? That sticks around.

What Actually Matters for Future-Proof Software

If I could distill the years between 2017 and today into a single insight, it’d be this:

Frameworks fade; the way you structure your software endures.

AI and Automation Changed Everything

At the time, having JavaScript run everywhere was groundbreaking. Today, AI and automation have transformed the landscape completely. Debugging, for example, used to mean long nights hunting obscure errors. Now, AI-assisted tools help pinpoint common issues in minutes, making troubleshooting more efficient - but its far from perfect.

Automated CI/CD pipelines have made updates effortless across every platform, no longer making deployment feel like a stressful space launch. Even components and tests can now be generated with AI, freeing developers from tedious, repetitive tasks to focus on higher-level design.

The future doesn’t care if your stack is cool; it cares how quickly and reliably you can adapt.

Security Finally Gets Its Due

Security was still a hot topic then too but not many knew what exactly to do beyond the understood norms and it often felt like an afterthought - we built fast and hoped nothing was vulnerable. Today, security isn't optional; it's essential from day one.

Modern threats, like AI-powered cyberattacks and vulnerabilities hidden deep in supply chains, weren't even on our radar back then. Regulatory compliance now also demands that security be baked into the foundation of every application. Building resilient software isn't about paranoia, (well it is slightly) it's about responsibility and longevity.

AI in Coding went from Novelty to Necessity (Almost)

AWS Lambda and serverless computing? Pure Revolution. Today we have coding platforms that generate entire apps for you (It can, but the stuff it generates is quite rudimentary). I have never once thought (nor will I believe) that coding can be completely replaced by AI - yet!

The reason I say this is because I have spent much more time debugging AI-generated code than I would my own. To start with, I wouldn’t have written many things the way it would, having learnt so much over the years, I structure things wildly different from the common scenarios that LLMs are trained with. But while AI-generated code still has a long way to go, its real value emerges elsewhere…

Today, we have low-code and no-code tools that can generate prototypes in hours instead of weeks. And it is things like this that make AI shine. The heavy lifting, the project starters, the strategic overview. After that it becomes a companion at best. This converts developers into strategic architects, crafting scalable systems rather than wrestling with mundane details. If anything, these tools elevated our roles by freeing us from the busy work.

Personally, I prefer using AI to handle specific parts of the code where structure or organisation can be enhanced, rather than relying on it entirely

I’d say LLM generated code has a long way to go and even if it gets there, you’d still need humans in the mix - and by definition - these humans are likely coders themselves because who else is going to debug AI’s mistakes?

I am hopeful though, and I am really looking forward to it because that means I can focus on things that really matter and leave the grunt-work to something else.

I’ll write about some of the tools I have reviewed in an upcoming article, giving you a better understanding on what’s out there now and how it can complement your workflow.

Microservices vs. Monoliths: Déjà Vu All Over Again

Just as 2017 had its React Native drama, today's hot debate is "microservices or monolith?" It's tempting to pick a side and argue until you're blue in the face but here's what history has taught us:

Neither one is a silver bullet.

Sure, a monolith might get your MVP out the door faster, but as complexity grows, it starts to feel like lugging around an increasingly heavy backpack. Microservices offer flexibility and modularity, but demand strict discipline to keep complexity in check.

The trick is to build a monolith with the future in mind. Code structured around isolated business units or features stands the test of time.

(Crap! That rhymed!)

Practically speaking, your code should communicate through clearly defined interfaces - a common protocol if you will. This could be REST, GraphQL, or an event-driven architecture, depending heavily on your infrastructure, team expertise and available resources

If each feature-driven section of your codebase can live and operate independently within your stack, transitioning from a monolithic structure to a standalone microservice becomes a surprisingly smooth process.

The Real Lesson is that The Framework Was Never the Point

I wasted way too many hours back then debating the merits of frameworks, only to realise years later how pointless it was. Winning arguments didn't make software any better; understanding longevity did.

Since then, I've been fortunate to lead numerous mobile development projects. One highlight was at Prudential, where we built federated React Native components used across various markets. The framework itself? Just a means, never the end.

A Final Thought, a Look Beyond Today's Trends

When picking your tech stack today, don't ask yourself, "Will this still be cool in 2025?" Instead, challenge yourself with, "Will this still be relevant in 2030?" If your answer depends heavily on a particular framework, you might already be falling behind.

Remember, tech stacks are transient, but good architecture and thoughtful design decisions are timeless.

WordPress MVC Plugin Reboot 2024

Jason Joseph Nathan — Wed, 25 Dec 2024 04:00:00 +0000

Thoughts on the simplicity of an older solution

Revisiting the WordPress MVC Router: A 2024 Update

So I stumbled upon an old database dump of Wordpress backups over the years and chanced a 2010 article I wrote that I thought was interesting. So I extracted, and decided to test everything out before I posted it on Geekist.

I’ve got to say, it really did surprise me. Logic from some 15 years ago still worked! So I decided I’d push the code to a repo, add some screenshots and give the article some well deserved love.

Fast forward to today, so much has changed with plugin development in WordPress, It has matured with frameworks and best practices, yet I’d still say that the core idea of a lightweight, custom router remains quietly powerful.

But let's revisit this in the context of what’s available now.

The WordPress Plugin Framework Landscape

Here are a few notable frameworks and tools for WP plugin development

WP Plugin Boilerplate: A standardized, object-oriented foundation for WordPress plugin development. It’s built on best practices and helps developers maintain clean, modular code.
WP Scaffold: A command-line tool that generates boilerplate code for plugins and themes. It doesn’t enforce MVC but provides a solid starting point for structured development.
Timber: It seems primarily focused on themes (templates), but Timber uses the MVC pattern and integrates with plugins to help structure admin interfaces.
Pods Framework: From what I gather, it does magic with custom content types and has powerful tools for building admin interfaces, with hooks and filters that align well with MVC-inspired routing.

Why Revisit the Simple Router?

Because with more features, comes complexity and a steeper learning curve. Sometimes, all you need is a lightweight, no-frills solution.

Also… there’s absolutely nothing close to creating the building blocks of your own reusable framework - especially for smaller or personal plugins.

The beauty of the router I introduced in 2010 (and the updated one below) lies in its simplicity. It maps URLs to controllers & methods and that gives you a great starting point to quickly structure plugins, avoid repetitive code and to scale functionality without introducing heavy dependencies.

And no, it’s not gonna replace WP Plugin Boilerplate for sure, but hey, there is really nothing stopping you from using both.

Updated Simple Router for 2024

Let’s dive into the updated router for 2024, which now includes a middleware implementation, auth checks, input validation and exception handling.

The New Router Class

class Router
{
  protected $middleware = [];
  protected $middleware_instances = [];
 // ...other methods below
}

So if we have a psuedo-MVC framework, it really does make sense to include some sort of middleware implementation. Here $middleware is a property holding defined middleware for the class and $middleware_instances hold instantiated instances. More on this later.

Constructor and Initial Setup

public function __construct(
  $route,
  $default_controller,
  $default_method,
  $middleware = []
) {
  $this->middleware = $middleware;
  $this->perform_auth_checks();
  $try = $this->route_it($route, $default_method);
  if ($try === false) {
    $this->default_route_it(
      $default_controller,
      $default_method,
      $route[2]
    );
  }
}

$route, in this case is an array consisting of the extracted $_GET variables, namely ‘page‘ and ‘action‘. This is provided by plugin.php when this class is instantiated. We try the provided route, if not we fall back to the default route. We also have an optional array $middleware saved.

Route Handling

The route_it method determines which controller and method to execute based on the request.

public function route_it(
  $controller,
  $method,
  $parameters = [],
  $default_method
) {
  try {
    $obj = class_exists($controller)
      ? new $controller()
      : false;
    if (!$obj) {
      return false;
    }
    $method_exists = method_exists($obj, $method);
    $default_method_exists = !$method_exists
      && method_exists($obj, $default_method);
    if (!$method_exists && !$default_method_exists) {
      return false;
    }
    $this->execute_middleware(
      $controller,
      $method_exists ? $method : $default_method,
      $parameters
    );
    return $method_exists
      ? $obj->$method($parameters)
      : $obj->$default_method($parameters);
  } catch (Exception $e) {
    $this->handle_exception($e);
  }
  return false;
}

We first check if a controller exists:

class_exists($controller);

then we check to see if the called action exists

method_exists($obj, $method);

or that at least that the default action (usually named index) exists

method_exists($obj, $default_method);

If none of the above checks out, we return false, otherwise we execute the defined middleware before passing control to the controller.

Middleware Execution

Middleware execution is optimized to reuse existing instances.

protected function execute_middleware(
  $controller,
  $method,
  $parameters
) {
  foreach ($this->middleware as $key => $mw) {
    if (!isset($this->middleware_instances[$key])) {
      if (class_exists($mw)) {
        $this->middleware_instances[$key] = new $mw();
      } else {
        throw new Exception("Middleware class $mw not found.");
      }
    }
    $middleware_instance = $this->middleware_instances[$key];
    if (method_exists($middleware_instance, 'handle')) {
      $middleware_instance->handle(
        $controller,
        $method,
        $parameters
      );
    } else {
      throw new Exception(
        "Middleware class $mw does not have a handle method."
      );
    }
  }
}

This is a simple way to ensure that we don't instantiate all the middleware for each request and is included here to illustrate how this can be done. However, another great way to include this is within your plugin's startup code itself. That way, your plugin's first page load wouldn't take too long if you have tons of middleware!

Fallback Route Handling

The default_route_it method handles fallback routes when the specified route fails.

public function default_route_it(
  $controller,
  $method = "index",
  $parameters = []
) {
  try {
    $obj = class_exists($controller)
      ? new $controller()
      : false;
    if (!$obj) {
      throw new Exception("Controller not found: $controller");
    }
    $method_exists = method_exists($obj, $method);
   if(!$method_exists) {
    throw new Exception("There is no default '$method' method found in $controller");
  }
    $this->execute_middleware(
      $controller,
      $method,
      $parameters
    );
  $obj->$method($parameters);
  } catch (Exception $e) {
    $this->handle_exception($e);
  }
  return false;
}

This method is pretty much the same as the 2010 version. The only difference is the added middleware execution. This method helps when your controllers have a default action (index in this case) and will be used as to display first page of the menu item that a controller handles

Authentication Checks

Basic authentication logic is enforced during construction:

protected function perform_auth_checks() {
  if (!isset($_SESSION['user'])) {
    throw new Exception("Unauthenticated access detected.");
  }
}

This saves you the hassle of checking for an authenticated user within each controller and it serves as an example of how you can include mandatory checks for your plugin.

Exception Handling

The handle_exception method provides a standard mechanism for logging and displaying errors.

public function handle_exception(
  $e
) {
  error_log($e->getMessage());
  wp_die(
    "An error occurred: " . $e->getMessage()
  );
}

The example above is rudimentary but you can expand on it to write to a log file, store a database entry (or even Sentry) when your plugin encounters exception.

How Do We Use This Exactly?

I'll have to admit, the original post - back in 2010 - was a little abstract so I hope the screenshot above helps to clear things up.

Each menu item on the left is a controller class you define. If you look at the URL, you'd see that $_GET variables list page=CRM with no action defined. So the page you see in the screenshot points to the Contacts controller class and the default index action. I am hoping to include a link to a GH repo with example code of this functionality some time soon, so do subscribe to the newsletter for updates. In the meantime, working code for the original router is still available here

Final Thoughts

I hope this article inspires you with at least one way of organizing your plugin code. If you have questions or thoughts, do share them in the comments!

Nginx Wildcard SSL and Beyond

Jason Joseph Nathan — Fri, 20 Dec 2024 03:08:16 +0000

A breakdown of SSL/TLS, Let’s Encrypt, and Mutual SSL with Nginx, covering wildcard certs, Cloudflare integration, and advanced security configurations.

Source

It's a Security Thing.

Jason Joseph Nathan — Sun, 15 Dec 2024 09:10:10 +0000

My old Heardable Inc boss was formerly in TV production. Heardable, as you might have heard of, was a brand analytics company way ahead of its time.

We were setting up a high-stakes professional YouTube interview with the Global CEO (David Sable) of Y&R (one of our incubators at the time), and we wanted to use this event to showcase our brand-new Heardable product - where I was CTO.

Everything was set up, and we were awaiting the arrival of David and other important folks.

I knew the app had a bug that required the Meteor Mongo DB to be reset to clear the cache before the demo.

You see, the thing about Meteor & Mongo is that in the early days of 2015, there was no way of telling their REPLs apart, Meteor's shell looked almost exactly the same as Mongo's shell.

So instead of typing this in the Meteor Shell:

> mongo reset

I typed this in the Mongo Shell

> mongo reset

Which. Well... It kinda... Uhm... Reset the entire DB.

Seriously though, which part of the above looked bloody different to you??

Right! I thought. Ten minutes to his arrival, and I just cleared out the DB.

Golden.

Okay, no problem, you got this. There's a backup you did a couple days ago. Grab it and restore it and everything's gonna be right as day.

But there was one problem.

My boss, whose account was going to be used for the demo, had changed her password after the backup, meaning she would have to "Reset Password" before the demo because the backup contained her older one.

Damn, I thought. Why in the world would someone change a password for a non-production server?

Two minutes to his arrival, and my boss walks in.

"All good?" she asked.

"Yes!" I said, "Just that I need you to do something real quick Can you reset your password?"

"Now?!" she asked. "You kidding?", she continues, in absolute disbelief and exasperation.

Calmly, I said, "Francine? Yes. Now."

She reset the password, and Ron Hart (the CTO of DropSuite) walked in just as the drama was ending.

"What's going on?" he asked. "Nothing," I said. "All good."

But Francine (my boss) couldn't resist chiming in, "He just made me reset my password!"

"Just a security thing" I said, lying through my teeth. Ron didn't say a word, but the look on his face said it all:

Yeah, sure it is

Meanwhile, David Sable arrives, and Francine leaves my office. I couldn't take the pressure and went out the back door for a smoke.

Ron came out to join me. He lit himself a cigarette, looked out into the car park in the same direction I was facing - and without turning his head - took a puff and asked,

"You f**ked up, didn't ya?"

I took a puff and said, "Yep."

He continues, in the same posture, "How bad?"

I said, "Well. How'd you rate resetting the DB?"

He replies, "Yep. Bad."

Were still not facing each other, casually looking out into the distance.

He takes another puff, then continues: "You fixed it?"

I replied, after another puff, "Yeah, restored a backup from a couple days ago."

He pauses for a bit, thinking about it, then asks absurdly,

"So you mean between the backup and today, she changed her password?"

I replied, "Yeapp."

He then shrugs, puts out his cigarette, and declares, "Yep totally a security thing Let's get back inside."

"Yep," I said, putting out my cigarette.

And as if it was nothing more than a smoke break, we walked inside to greet the VIPs and show off the new product demo.

Later, reflecting on the chaos of that day, I realised something. Handling high-pressure situations like this didn't come from my technical skills, it came from DJing in clubs in my younger days.

When DJing, your time bomb resets every new song you play. Especially when you're playing uncharted genres, its not bizarre to have just 30 seconds on the clock and not have a next song.

You'd have to pick a song, put in a CD, cue it to the point you wanna play it, say something ridiculous to hype up the crowd, and play the next track - all as if it were deliberate and perfectly intended.

There were times I had to do all of that in just about 10 seconds too.

In those moments, you're not just playing music - you're a freggin' time magician, convincing everyone that this is exactly what they came for.

Because fundamentally, the clock aint gonna stop for no one.

It's what you do in that time that matters.

Right in the neck that was.

Building a Zoomable UI with Meteor.js & Greensock

Jason Joseph Nathan — Sun, 04 Jan 2015 04:00:00 +0000

An exploration of Zoomable User Interfaces (ZUIs) with Meteor.js and Greensock & a unique responsive UI design technique

Source