I want you to imagine someone for me. Her name is Jessica and she is 17 years old. She lives in a two bedroom apartment with her mother and uses an old laptop she got from one of her mom’s ex boyfriends. With it, she browses the portals that serve as her connection to the community constructed...
Leatherbound Pt2: Front-end Architecture and Data Schema
Ok, so last time I said there would be some designs in this post. That was a complete fabrication. (Or maybe an enhancement of the truth?)
I've been thinking a lot about harder problems: 1: I love Web Components. 2: Polymer has all the compatibility of car components (ie it only runs on Chrome).
So I'm leaning more towards Mozilla's X-Tags to do some of the heavy lifting of Custom Elements, use HTML Imports, and leave Shadow DOM out of the picture. The problem with this is that X-Tags does approximately nothing for you with regards to templating, data binding, or anything else you need to do.
For some reason, I also want to move away to jQuery. Vanilla JS has come a long ways since 2004, and maybe if I use less frameworks of questionable utility, the lighter the app will be. To that end, I wrote doubledollar.js, a simple wrapper around some of the pain points of DOM (web components stuff, abbreviations of common operations, AJAX things, some promise stuff, etc). I expect to develop it more as I dig more into Leatherbound.
One the data side, I had a painful reminder that I'm no longer in key-document land and that Google Cloud DataStore (aka BigTable) stores simple schemaless records. So I had to do some actual thinking as to my data store.
What I'm thinking is that an entire post is stored as (sanitized) HTML in a single value in the database. Make sure that user-facing content and searchable text are in the text content of it. We're already making heavy use of custom tags in front-end, so why not use them in the data store, too? The software can semantically know exactly what happened, widgets can be updated, and the messy implementation details (like the code to embed a video) don't appear in the DB. Use tags like <lb-event>, <lb-picture>, <lb-tag>, <lb-mention>, etc. The software can easily parse these out for various reports (lists of media, tag clouds, etc).
For indexing, hash-tags and at-mentions would need to be also stored, but I consider these cache columns for the benefit of querying.
My next problem is the posting and editing process. Because of uploading media, posting an entry is not a simple POST request, but several. Clean up of media of deleted posts would need to follow (unless I take the tumblr approach and store everything forever). The alternative is to upload all the media at once, but this sounds like a recipe for bad user experiences (long post time, higher chance of failure, and unusual behavior).
I've been using the i3 Window Manager for a little while now on my laptop. For those of you who don't know, i3 is a tiling window manager somewhere between wmii and awesome.
I personally find it's minimal enough to be quite nice on my 15" laptop, but still implements useful things like notifications, systray, and a normal way to log out.
My customizations are available on my github with config file an support scripts. The big things it does is set up i3lock (with a fuzzed background, thanks to Image Magick), starts a bunch of baseline stuff, and fixes the Chrome App List.
So keyboard-based window management is here to stay for me. Good luck getting me on vim or emacs, though.
I'm working on a new project which I thought I'd turn into a series. It's nothing fancy or sophisticated. The code name is Leatherbound, and it's a diary/journal web app. This first post I just want to lay out the premise and some of the requirements and guidelines.
Easy to use
Responsive design
Some of the decisions I've made:
Using Material design: Because why not? At least it's not more bootstrap)
Google AppEngine: scalable and free limits
Google Cloud Storage: I think NoSQL will work better than SQL
Python: Obviously
Google Login
Using Polymer (although that might not be mobile friendly? May ditch it)
Some features:
Optionally include events that have occurred since the last post (from Google Calendar)
Full WYSIWYG (I'm thinking inspired by hallo.js, but probably re-implemented for material)
Embedding media, including photos
Some other random details:
First screen after login is the new entry screen, and it should load fast. I figure its the #1 thing people do when they login.
May look into Ember? The initial load time is a concern against the previous requirement and Polymer's already slow loading.
Next time, I'll be showing the prototype interface I've got going so far.
Second Query: I am at a loss to find a voice changer, that I can route from a small (but quality) microphone to am amplified personal PA system. There are many novelty voice changers for halloween and such. But none of them are loud, or clear enough to be used in crowded or wide open spaces if being used with a mask that covers my face and muffles the sound of my voice. Any advice? hiltonwalls at gmail com.
Seeing as I'm a maker, I'd have two ideas how to do this:
Tear apart an off-the-shelf voice changer and exchange the speaker or other components for your own to get the behavior you need.
Build your own voice changer
Either way, check what others have done (Hack A Day).
Keep in mind good speakers just take space. You can't avoid this.
I thought I would formally announce that I have changed companies. I'm now in a position of management in a software as a service company. If you want specifics, I'm sure you can find out.
I know I haven't been posting much, but this is Important. Gnome needs help.
Even if you don't personally use the Gnome desktop environment, you have certainly benefited from their work: GTK (used by Gimp, Pidgin, and others), practically every Linux distro has something they developed or promoted (gconf->dconf, D-Bus, etc).
About five years ago, I bought a cushy couch for my office. (Okay, yes, I did get the model that could flatten into an emergency nap station, but let’s just say that I plan for contingencies—it sounds more professional that way.) Our projects required a lot of office-to-office visiting to discuss situations in person, and eventually, said couch (and therefore, my office) became a veritable beacon, attracting anyone looking for an excuse to decompress. Such is the life of a one-couch, 50-chair business.
This has 0 technical content. But it's an important aspect of people. I guess it's just a reminder that everyone has inner demons and struggles with something. Nobody is all strong all the time.
So I have the raw database from the Mac version of the Lytro software. Each "image" is a directory with dm.lfp, raw.lfp, stack.lfp, stacklq.lfp, and thumbnail.jpg
The first thing I did was write a script to make galleries from the albums because UUIDs are incredibly unhelpful.
Looking at the other files, you can use lfpsplitter to get the sections out of LFP files. (The format has been reversed, but I'm not writing any software yet.)
I looked over everything. stack.lfp contains some H264 images, but nothing terribly useful. (Nothing like the jpegs lfpsplitter was made for.) However, raw.lfp contains the raw pixel array from the CCD. And raw2tiff can read this. So you just run:
raw2tiff -w 3280 -l 3280 -d short raw_imageRef0.raw raw.tiff
And you get what I'm calling the "bug-eye" view. It's still needs to be demosaiced  (the process of turning raw CCD pixels into RGB pixels) and the bugeye thing is a problem (microlens problems).
But this solves one of the problems: turning the raw file off the camera into a usable array of pixels. Too bad I don't know how to get them off the camera or what to do with the pixels after I have them.
I'd like to write my own photo manager for my Lytro camera. My basic problem is Linux support.
I'm not sure what platform to use. HTML5 (in the way of CouchDB + Chrome Extension) is appealing. Easy-to-build interfaces, computer independence, etc.
On the other hand, all the binary files & processing means that a native app might be easier to write. In particular, dealing with dynamic display of "living photos" (stuff with refocusing and other light-field effects).
In any case, having to research and implement the algorithms involved sound like the opposite of fun.
This is how I learned KiCad, the electronics design package. It's great if you already have some idea about things like electronics and schematics and just need to learn the tools.
Since I've watched this, he's released his whole KiCad course for free. I haven't really looked into it, since I've got other stuff going on, but it might be helpful for you.
At work, we have a big display (that will be) mounted on the wall and driven by a Beaglebone Black. We thought it'd be cool to be able to show each other what we're doing by throwing it up on the screen.
After some research, I decided to use x11vnc. I thought I'd have to SSH in to the Beaglebone and set up a port forward. But then I read the man page for x11vnc and discovered VNC reverse connections.
A VNC reverse connection is when the VNC client (the one displaying) listens and the VNC server (the one with the applications) connects to it. Using this, I could create a simple daemon with off-the-shelf programs and the tiniest of shell scripts.
Display
The Beaglebone Black already has an .xsessionrc on its user, so you just configure it to autostart X and then add xvncviewer -listen 0 -fullscreen & to the end. Easy peasy.
As a bonus, we set up a hostname and mDNS on the Beaglebone so that we don't have to deal with static IPs, servers, DNS entries, etc.
Clients
The client script is a bit more involved just because I went a little overboard on options to make sure weirdness didn't happen. We install this script on each machine we want to connect to the display.
Due to our individualized configurations, we have different options to send to x11vnc.
I have two displays, so I use -clip xinerama0 and -clip xinerama1 to switch between them.
My coworker has a display of a higher resolution than the display mounted, so he uses -scale 3/4 to
Does it work?
It works well! Videos don't play well and there's a lot of tearing, but it works. Multiple users work fine, too; they just stack up in connection order, so the newest one is on top.
In fact, the only changes I want to make are things like removal of the desktop environment on the display and the set-up of a default application.
USB has become so commonplace that we rarely worry about its security implications. USB sticks undergo the occasional virus scan, but we consider USB to be otherwise perfectly safe - until now.
This is the actual talk going into full detail on BadUSB. Some of the attacks they’ve discussed are meh, but some are horrific. It is important to note that BadUSB itself does not depend on any security holes; it is a systemic design vulnerability. None of the techniques I highlight use a security bug, either.
DISCLAIMER: I am not a security researcher or by any means a security expert. I am a software developer who's always been better at building things than breaking them.
The two that really stuck in my mind are an Ethernet+DHCP attack as a stepping-stone for MITM, and fingerprinting attacks.
They discuss an attack where a USB device acts as an network device and has its own DHCP server (there doesn’t need to be any real-world network connection on the device for this to work). When you plug it in, the Computer sees a network connection and autoconfigures it with DHCP. The device returns a DHCP advertisement with a public DNS server. This server is added to the system’s pool of DNS servers, regardless of interface it came from, allowing it to be used with any request. Of course, whence you’re using a malicious DNS server, that opens a pile of attack vectors.
This DHCP attack could be mitigated by adding a verification to the DHCP daemon/service: Just check to see if the interface being configured has a route to the advertised DNS server. If not, don’t use that DNS server. Unless the device does have a network connection. Or it has the route and DNS server in the device as well.
The second attack that caught my eye is a flash drive fingerprinting attack. (This probably only works on devices with significant storage.) A device uses the behavior of the USB host to fingerprint it. If it is an operating system, show a plain-jane flash drive. If it is a BIOS, show a bootable partition. BIOS boots this, and the malicious device installs a rootkit and boots the harddrive.
This application of fingerprinting is of course mitigated by setting boot order correctly, especially since many BIOS now support selecting a boot device in a menu for one time.
The real danger of fingerprinting is that it hides malicious interfaces from scanning. It would be easy to build a stateless stand-alone device that displays the enumeration of a USB device (Raspbery Pi Model A, PiTFT, and lsusb). But if that device is fingerprinting hosts, this scan may or may not show anything out of the ordinary.
The biggest WTF in all this, of course, is why on earth the firmware for a USB device is updatable over USB in the first place? We have test points and JTAG and ICSP for a reason. Karsten & Jakob in fact recommend that USB-based reflashing be disabled at the factory.
For extra fun, reframe that entire discussion in the context of Android phones. I don’t know if Android applications have the ability to define new device profiles for the phone/tablet on unrooted devices. If they do, then all an attacker has to do is get their application on the phone and wait for the user to plug it in to a computer.
The BadUSB website has a proof-of-concept that runs on a rooted Android phone. It demonstrates an attack where the phone runs a DNS server, allowing DNS-based MITM.