Content Type Advertisement

October 18, 2017 2 comments

How does an HTTP Client know what Representations for a Resource are available from an HTTP Server? The answer is simple: Use the HTTP Link Header, Luke!

Read more…

Advertisements
Categories: Articles, Projects

Webpage Head/Tail bookmarklets

Some sites use AJAX to load content into a DIV. This is cool, but some (all?) browsers don’t automatically scroll when more content expands the DIV past the bottom of the window. It’s pretty poor UX to have to manually scroll a webpage when you want to follow along with the output as it goes.

In order to Not Lose My Mind, I wrote a quick JavaScript bookmarklet that scrolls to the bottom three times per second. Here’s the simple code:

“Tail” bookmarklet

javascript:window.tailer = window.setInterval(function () {
window.scrollTo(0,document.body.scrollHeight);
}, 500);

NOTE: I have formatted this with new lines and spaces for this post. You can remove those.

You just create a new bookmark link in your bookmarks toolbar and dump that code in there. Name it something like “Tail” and away you go!

Now, once you’re tailing a webpage, how do you get back to the top? Well, you could just refresh the page. But, maybe you like symmetry and you’d like to do this with a bookmarklet. You’re in luck!

“Head” bookmarklet

javascript:window.clearInterval(tailer || 0); window.scrollTo(0, 0);

This not only cancels the “tail” callback, it also scrolls to the top. Yay!

Categories: Projects

workhere: Quick environment setup for Linux command-lines, Python and Node

April 13, 2017 Leave a comment

Python’s virtualenv-wrapper is amazing. Use it whenever possible.

Still, there are times when you’re on a system over which you don’t control all the things. For example, I am working in a project that uses make in some odd ways and puts binaries in buried directories. It does, however, use Python’s virtualenv and the Node.js Package Manager yarn.

Per standard practice, the Python virtualenv is named venv. Consequently, the binaries for Python’s virtualenv get buried under venv/bin.

Also per standard practice, the Node.js binaries get buried under node_modules/.bin.

I wanted one command to activate my Python virtualenv and add all those binaries to the path. Here’s what I came up with:

alias workhere='export PATH=venv/bin:node_modules/.bin:$PATH && \
                source venv/bin/activate'

I put that in my .bashrc file, so that it is available to any shell I open.

That way, I simply have to cd /path/to/project and then type workhere.

Problem solved.

Categories: Projects

Why Git

December 15, 2016 Leave a comment

A coworker asked me why my team uses Git. He was interested also in a comparison with Subversion, which his team uses. Here’s my response.

Read more…

Categories: Projects

SSHFS: Hacking Linux files from a Mac

December 14, 2016 Leave a comment

I’m a Linux fanboy. Used to love Microsoft, now…not so much. Used to hate Mac, now…well, I love their hardware, and OSX sure has a pretty face.

Anyway, these days, I spend a ton of time with OSX, even though I prefer developing on a Linux Desktop in a VM. But there are times it would be nice to spin up a new VM and mess with its files using some tools installed on the OSX host.

Today I found out how.

Install SSHFS

We’re just going to use the same trick that is available to Linux users, but we have to jump through some hoops to get it on Mac.

Helio Tejedor’s article has a ton of detail about installation, but I found the most relevant bit is this:

 

The easy way to install SSHFS is navigate to http://osxfuse.github.io and download two files:

  • OSXFUSE 2.7.3
  • SSHFS 2.5.0

Do that, but just pick the latest two versions listing right on their homepage.

Manually test it out

Digital Ocean’s article is, like most Digital Ocean articles, excellent documentation. The section “Mounting the Remote File System” has a detailed explanation about how to mount remote drives using SSHFS. I just needed these two lines for my test VM (at IP address 192.168.56.101).

sudo mkdir /mnt/192.168.56.101
sudo sshfs -o allow_other,defer_permissions user@192.168.56.101:/ /mnt/192.168.56.101

The observant reader will notice that:

  • The user is the name of the SSH account that can connect to the box.
  • I am “cheating” by using the IP address for the folder name…
  • …which may have unexpected results when my VM gets a new DHCP lease.

I’m good with all that. It works!

Script it

Mounting, unmounting, making directories…boring. I scripted this as mountvm, and now I have a simple one-liner to mount/unmount/etc. that mimics ssh.

Here’s the magic sauce, for your discerning palette.

#!/bin/bash
user=$1
host=$2
sudo umount /mnt/$host
sudo mkdir -p /mnt/$host
sudo sshfs -o allow_other,defer_permissions $user@$host:/ /mnt/$host

Merry Christmas!

Categories: Projects

Product Management and Development Ten Commandments

December 8, 2016 Leave a comment

Jim Montagnino shared these principles with me recently. With his permission, I am posting them here.

  1. KISS – Keep It Simple Stupid, Less is always better
  2. Make it “Idiot Proof” – a user or admin should not be able to break it
  3. Always keep in mind our customer’s ability to consume what we can build
  4. Keep security both internal and external in the forefront
  5. Configuration – not coding
  6. Leverage inherent Platform Capabilities whenever possible – even at the expense of functionality (go back to first bullet)
  7. Phased approach – don’t boil the ocean on each release
  8. Keep upgradeability in the forefront
  9. Listen to our customer feedback and stay in tune with the market
  10. Sizzle Sells – consider POC & Special Projects to help drive sales

I have a wild ambition to expound on each point, but I will save that for separate posts.

Thanks, Jim!

Categories: Business, Projects

The Future of JavaScript is X

June 4, 2015 1 comment

JavaScript in 2015

JavaScript has gotten way better than it was originally. The Good Parts actually make JavaScript a pleasure to program (and much closer to Python, IMHO). Firebug and other in-browser debuggers make it possible develop large-scale projects without losing your mind.

Browser improvements and Node.js have expanded the speed and reach of JavaScript. Jeff Atwood postulates that

any application that can be written in JavaScript, will eventually be written in JavaScript

Node.js is especially compelling, because it opens up the idea that all software might eventually run with JavaScript, be it in the browser or on the server. Write once, run anywhere? Maybe. But maybe not.

The Problem with JavaScript

JavaScript in the browser has one huge gaping hole: It must be sent in the clear. For a browser to run it, this code must be valid JavaScript. Sure, you can encode it and decode it on the fly, but the decoder has to be written in JavaScript. This means that any sufficiently-diligent programmer can reverse-engineer any JavaScript code. There is no way to hide implementation details using JavaScript.

Web APIs to the rescue?

Enter Web APIs. Here, we separate out business logic and other implementation details from the front-end JavaScript. We place them in back-end server code, be it Node.js, Python, Ruby or COBOL (yikes!). No browser ever receives the code that runs on the server, so that’s great, right?

Actually, no. Web APIs do not protect a sufficiently-diligent programmer from documenting your process. In fact, many Web APIs are publicly available, which encourages use. And that’s good. But it does not protect your process.

In reality, Web APIs just complicate things. If your front-end has to call your back-end, then you must implement logic to parse/emit data structures that can be sent across the wire. If you’re using Node.js cleverly, you can implement that once and use it in both places. (Browserify is your helper, here.) But if you are in a heterogeneous environment, you may have servers running Python, .Net, J2EE (shivver!) and Perl. Each of these must also implement parse/emit logic. (“Write once, run anywhere” just went out the window!) Keeping all these in-sync (esp. with versioning in the URL!) is a nightmare.

Chapter 5 REST to the rescue?

Chapter 5 REST would help here, esp. with anarchic scalability. But many developers don’t understand Chapter 5 REST, and fewer are willing to collaborate at that higher level. This is why Web APIs have taken off: it’s low barrier to entry, and you don’t actually need to think about how your own application might be a subset of a broader (global) problem space. (And that’s all I’m going to say about Chapter 5 REST in this article.)

Browser plug-ins to the rescue?

Flash used to be the de-facto way to get closed content to the browser. It’s old news by now that Apple iOS doesn’t run Flash. Microsoft at one time wanted to do the same with its browser…but now they support Flash by default. I’m not sure how I feel about that.

You could install another binary plug-in, but installing browser plug-ins is an administrator’s nightmare. Enterprise security policies may also allow BYOD, but then you have to install the plug-in on devices outside your enterprise control. Not fun.

The original browser plug-in was Java. I don’t write many Java applets these days. Do you?

JavaScript’s replacement

So, the killer of JavaScript is its readability (both machine and human). If you want to protect your implementation details, then you must expose as little JavaScript as possible to the browser. Two relatively new technologies (2011 and 2004) have emerged that enable extremely-thin JavaScript browser clients: websockets and Canvas.

Wait, wait! Couldn’t we do this with AJAX and images?

Well, maybe. But not well enough.

First, AJAX really doesn’t allow the server to send to the browser directly. Several tricks (including HTTP Long Polling and others) have sort-of made that possible. But it hasn’t been really good enough to support massive server-initiated redrawing.

Second, messing with images messes with the DOM. Anytime you mess with the DOM, the browser tends to get really slow. Canvas allows much faster updates that do not impact the DOM.

Websockets and Canvas to the rescue!

It is almost dumb-simple to setup a websocket connection in a browser with JavaScript. The hard part is building the parse/emit logic and then the code that processes incoming messages. Out-going messages are trivially simple–just a single function call. If you get rid of the hard part, then you’re left with a bare-bones, lightweight client. Here’s how.

Don’t implement application-specific message processing in your browser app. Not one bit. Just implement code that takes the server commands and renders them on the Canvas. You could (if you’re lazy and inside a trusted network with no fear of Bad Actors) let the server send actual JavaScript code and eval it client-side. That would, however, be evil.

If you’re a bit more diligent, you still can build minimal code to process rendering commands on Canvas.

You’ll also need to send back keyboard and mouse events to the server. But that’s a very tiny bit of info, namely the (x, y) coordinate, which mouse button and/or key was pressed. The server can process that and stream more rendering commands back via the websocket.

What about multimedia?

Any technology gets harder with multimedia. The same is true here. I’m not going to focus much on that now. However, take a look at WebRTC for peer-to-peer media connections and streams. Just overlay a Canvas on top of a element, and you’re still able to control the video with the least amount of front-end code. Or, if you have tons of server resources (like a Media Server farm), then you could conceivably proxy all the media streams and issue image updates via websockets to Canvas. (That way lies madness, methinks.)

Isn’t this more like VNC?

Maybe. It’s a spectrum that depends on how lightweight your client code is. On the one end, you could send partial images and blit them where needed (using drawImage)–this would be like VNC. On the other end, you could implement higher-level functionality with additional Canvas methods–this would be more like the X Window System.

What about SVG?

I’m no expert, but you could replace Canvas with SVG. It’s a different beast, but the same principal applies, and implementations fall along the same spectrum from VNC-like to X-like.

Really, now…why would anyone do this?

Companies like to protect their intellectual property. Arguably, a JavaScript front-end is protected by technology (HTTPS) and copyright law, but there are some for whom these protections simply are insufficient. They already use similar technologies like VNC, Remote Desktop Protocol and exported X-Window sessions. This websockets/Canvas solution has one major advantage over those: it will run in the browser without any installation…as long as JavaScript is turned on.

 

Categories: Projects