Tomer Weller / Blob

ESP32 - first steps

Mon, 09 Jan 2017 01:00:00 +0000

This post describes my first steps with ESP32. It was originally written as preparation for TA’ing communications week in MIT’s fabclass. I cover basic setup, firmware deployment and a hint of benchmarking.

Warning: This post was written in November 2016. ESP32 is brand spanking new and should be considered a moving target.

Contents:

What is the ESP32?
Hardware Setup
Programming
Ring Oscillator benchmark
More Resources

What is the ESP32?

ESP32, successor to the beloved ESP8266, is system on a chip (SoC) that can do (almost) anything:

Real concurrency with two cores
WIFI
Bluetooth
BLE
Much more

Espressif, the manufacturer, have been kind enough to send some units of their new ESP32 modules for evaluation. (huge thanks to John Lee @EspressifSystem) I will demonstrate basic connectivity, different ways to program it, and basic benchmarking.

Hardware Setup

Equipment Used

ESP32 WROOM32 module. This is Espressif’s own ESP32 module. It’s safe to assume that we’ll see ESP32 used in modules from 3rd party manufacturers in the near future (AI was the lead module manufacturer for the ESP8266).
ESP32 Breakout board. Espressif provided us with simple breakout boards that expose all I/O pins and physical buttons for RESET and BOOT MODE. There are other boards available to order as well as designs to mill your own.
FTDI Cable
3.3V Power Supply (up to 500mA). DO NOT USE THE FTDI POWER - IT CAN’T PROVIDE ENOUGH CURRENT. (TRUST ME - I’VE TRIED)

Note: soldering the module to the breakout board proved non-trivial, the ground plane is very large so a high wattage soldering iron is recommended for soldering the ground pads.

Basic Connectivity

VCC (ESP32) -> 3.3V (POWER)
GND (ESP32) -> GND (POWER)
GND (ESP32) -> GND (FTDI)
TX (ESP32) -> RX (FTDI)
RX (ESP32) -> TX (FTDI)

Sanity Check

Open a terminal emulator on the FTDI port with a BAUD rate of 115200
Hit the RESET button

⇒  miniterm.py /dev/tty.usbserial-XXXXXXXX 115200
ets Jun  8 2016 00:22:57
rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
....
IDF version : master(db93bceb)
WIFI LIB version : master(934d079b)
ssc version : master(r283 4d376412)
!!!ready!!!
mode : softAP(26:0a:c4:00:27:f4)
dhcp server start:(ip: 192.168.4.1, mask: 255.255.255.0, gw: 192.168.4.1)
+WIFI:AP_START

Not only does it work, it even defaults to opening a public access point

⇒  airport -s | grep ESP
ESP_0027F4 26:0a:c4:00:27:f4 -14  1,+1    Y  -- NONE
When a device enters the network:
n:1 0, o:1 0, ap:1 1, sta:255 255, prof:1
add 1
station: 80:e6:50:27:b6:62 join, AID = 1, g, 20
+SOFTAP:STACONNECTED,80:e6:50:27:b6:62

I couldn’t find any other interesting things in the provided firmware. In case you were wondering, like me, whether ESP8266’s AT command-set works in this prompt, the answer is no. It’s not very clear what commands do work here. (If you know of some, leave them in the comments below)

Programming

FreeRTOS

Before programming this chip it’s crucial to understand that, unlike other embedded systems, the ESP32 comes with a light operating system - FreeRTOS. The following methods to program this chip don’t replace the FreeRTOS firmware, but rather deploy applications for it to run. I imagine that in the near future we’ll see other operating systems or no-os approaches for reprogramming these chips.

There are currently two methods to program the ESP32: the ESP-IDF and the ESP32 arduino Core.

ESP - IDF

Espressif IoT Development Framework is a set of open source libraries and tools to facilitate deployment of apps to ESP32s FreeRTOS.

Code Example : HTTP GET request using the ESP IDF

ESP32 ARDUINO CORE

Espressif have also been hard at work to get the maker community happy and makers love Arduino. The ESP32 arduino core integrates ESP-IDF deeply into the arduino tools. This includes providing a WiFi API that is almost 100% compatible with existing wifi shields for arduino.

Code Example : HTTP GET request using the ESP32 Arduino Core

Note: currently, to take advantage of the concurrency capabilities - IDF is the way to go.

Ring Oscillator benchmark

Ring oscillator tests measure the minimal amount of time it takes for a signal to get out of a chip and back through peripherals.

In practice, it means shorting two pins with a jumper, defining one as input and the other as output, and then writing and reading as fast as possible. The result is recorded with an oscilloscope connected to the shortened pins and ground.

Here, I measure both programming methods mentioned earlier:

FreeRTOS (code)	Arduino Core (code)
1.63MHz	1.05MHz

Conclusion: the Arduino program is about 35% slower than the lower level FreeRTOS program. However, usually in these type of tests, the portability of arduino code comes with a much bigger performance drop. Good job, Espressif!

Note: These tests only occupy one core. The second core is free to perform other tasks, such as networking. Example.

More Resources

Thanks:

John Lee and espressif for providing the hardware.
Tal Achituv for help with soldering and the oscilloscope.
Jonathan Bobrow for feedback on this post.

Clojurescript/Reagent : importing React components from NPM

Sat, 25 Jun 2016 04:59:59 +0000

This post describes, step by step, how to setup a workflow for importing React components from NPM, using Webpack, and incorporate them in your Reagent views.

UPDATE (June 17th, 2017): A year later, this post and method are very much still relevant. I’ve made a small update to take advantage of the :foreign-libs option, as suggested in the comments (Thanks Andreas and Alex!), which reduces the plumbing necessary.

Motivation

Any Javascript developer using a modern build tool can easily test and incorporate React components from 3rd party developers in their app. It’s usually just a matter of declaring dependencies, building and importing.

Moving to Clojurescript and Reagent has been amazing in many ways but I just couldn’t wrap my head around a comparable import flow.

The workflow I will describe employs NPM as a dependency manager and Webpack as a build tool. The build artifact is added as an external Javascript dependency to an otherwise (pretty) standard Leinnnigen build process.

This solution does not use Cljsjs in anyway.

Why not Cljsjs?

Cljsjs is a great community effort to package common Javascript libraries in a Clojurescript friendly way. However, it has some shortcomings.

Very few packages compared to NPM or Bower. Whenever I look for something it’s usually not there.
Packages are mostly out of date compared to their NPM counterparts. This make sense because with NPM packages the author/maintainer of the library is the same person as the maintainer of the package. That’s not the case with Cljsjs.
Packaging a library is not trivial. The community’s usual reply to the import issue is “just package it yourself”. Sending someone who wants to fiddle around with a 3rd party react component, to package the dependency themselves is, in my opinion, cumbersome. This also leads back to problem #2.

Zefstyle

In this example we’ll start with a simple frontend-only Reagant app and setup a workflow that will allow us to add a react-player component to it. Let’s call this project Zefstyle. You can also skip this altogether and just jump to the finished result here.

Starting with a template:

$ lein new reagent-frontend zefstyle && cd zefstyle

For sanity - Let’s see that it’s working

$ lein figwheel

While that’s running, open public/index.html in your favorite browser. You should see a page that says “Welcome to Reagent”

Since we’re running figwheel, we can change that live. In public/index.html change the header to “Zef Style” - You should see it updating within seconds. You can then close fihghweel for now.

NPM Setup

Let’s create a minimal package.json file. We can either do it interactively with npm init or just manually create a package.json file:

{
  "name": "zefstyle",
  "version": "0.0.2",
  "author": "tomer.weller@gmail.com",
  "scripts": {
    "watch": "webpack -d --watch",
    "build": "webpack -p"
  },
  "dependencies": {
    "react": "15.5.4",
    "react-dom": "15.5.4",
    "webpack": "1.13.1",
    "react-player": "0.18.0"
  }
}

package.json remarks:

We import react and react-dom although they are not a hard dependency of react-player and more than that - we already have a React instance in our code, the one that Reagant depends on. Why? There is an order of execution issue when relying on Reagant’s React dependency. This also means that we will later need to exclude Reagant’s React dependency so that we don’t have two React instances.
I’ve included some shortcuts for webpack scripts. They are not necessary but will come in handy.

Install dependencies:

$ npm install

All of our dependency tree should now be in the node_modules directory.

An alternative approach to this step would be to use the lein-npm plugin. I’m pretty comfortable with npm so I decided to do it myself.

Webpack setup

Our webpack setup will be pretty minimal - no fancy loaders. It consists of a definition file webpack.config.js and an entry script that bootstraps our imported libraries to the window object.

webpack.config.js :

const webpack = require('webpack');
const path = require('path');

const BUILD_DIR = path.resolve(__dirname, 'public', 'js');
const APP_DIR = path.resolve(__dirname, 'src', 'js');

const config = {
  entry: `${APP_DIR}/main.js`,
  output: {
    path: BUILD_DIR,
    filename: 'bundle.js'
  },
};

module.exports = config;

We basically defined our entry point script as src/js/main.js and our output artifact as public/js/bundle.js.

Our entry src/js/main.js should look something like:

window.deps = {
    'react' : require('react'),
    'react-dom' : require('react-dom'),
    'react-player' : require('react-player'),
};

window.React = window.deps['react'];
window.ReactDOM = window.deps['react-dom'];

I usually prefer not to bind too many objects to the global window context, that’s why I push whatever I can into window.deps. With that said, React and ReactDOM must be on the global window context because that’s where components expect them to be.

Now we can either run

$ npm run build

For a onetime build, or:

$ npm run watch

For a continuous build that watches for changes in our code. Given that the Javascript code should remain pretty static the watch might be redundant.

Leiningen project setup

Like I mentioned before, we’re counting on webpack to bring React into the picture. That means that we need to get rid of the cljsjs.react & cljsjs.react.dom packages that reagant depends on.

In project.clj let’s change our dependencies to be:

:dependencies [[org.clojure/clojure "1.8.0" :scope "provided"]
             [org.clojure/clojurescript "1.9.562" :scope "provided"]
             [reagent "0.6.2" :exclusions [cljsjs/react cljsjs/react-dom]]]

And add an external dependency to our webpack generated bundle.js through :foreign-libs. We need to add the following to all build profiles:

:foreign-libs [{:file "public/js/bundle.js"
                :provides ["cljsjs.react" "cljsjs.react.dom" "webpack.bundle"]}]

Notice how our foreign lib satisfies all react dependencies and also add a convenience namespace, webpack.bundle, for importing the external bundle.

At this point it’s a good idea to cleanup and re-run figwheel.

$ lein clean && lein figwheel

Grand finale

Now that we have everything in place we can add the react-player to our main Reagant view.

in src/zefstyle/core.cljs let’s add the webpack.bundle dependency to our namespace:

(ns zefstyle.core
  (:require [reagent.core :as reagent :refer [atom]]
            [webpack.bundle]))

and change our home-page function to be:

(defn home-page []
  (let [react-player (aget js/window "deps" "react-player")]
    [:div
     [:h2 "Zef Style"]
     [:> react-player {:url "https://youtu.be/uMK0prafzw0"}]]))

Notice the special :> syntax for using pure React components.

opening public/index.html should yield something like this:

Voila! We brought the pure JS react-player component into our Reagent view.

To bring in new components we just need to declare them in package.json, require() them in main.js and rebuild.

Caveats:

JS dependencies are not processed by the Closure compiler so they do not get advanced optimization, only whatever webpack is setup to do.
Setting up this process is not trivial. However, it only needs to be done once and from then on it’s a smooth sail. Also, automating the process or part of it sounds like a feasible task as part of a lein plugin. I’ll look into that when some time frees up.

Let me know if this was helpful, requires some fixups or if it’s complete rubbish.

Thanks to:

Thariq Shihipar for suggesting this approach although condemning the use of anything other than Javascript and React.
/r/clojurescript, Clojurians on Slack and especially @sbmitchell for helping me troubleshoot.

Setting up a free live streaming solution in two hours

Tue, 22 Mar 2016 04:59:59 +0000

Note: a previous version of this post had some licensing terminology issues. This post discusses Free software.

Last Sunday the Media Lab hosted a Public Dialogue on DRM and the future of the Web. Amongst the speakers was Richard Stallman (aka RMS), founder of the Free Software Foundation. Although there was a lot of interest in the event from outside of the media lab, it couldn’t be streamed with MIT’s setup even though it was being filmed. MIT’s video streaming service is proprietary and Stallman will not use, or even take part in using, software that is not completely free.

Richard Stallman, Danny O’Brien, Joi Ito, and Harry Halpin. Photo: Jon Christian

Earlier that day, during a lunch hosted by Joi Ito, Tal Achituv and myself toyed with the idea of deploying a WebRTC based solution that is free and will be approved by RMS. After doing some research, it seemed that there are indeed free WebRTC options for broadcasting. Now, a couple of hours before the panel, we decided to go for it.

This resulted in two hours of hectic coding, setup and equipment search.

The Setup:

Photo: Tal Achituv

Making this diagram took more time than building a free streaming solution

Media Server

Kurento (LGPL-2.1) is a free media server. It implements the WebRTC spec and uses GStreamer under the hood for any multimedia processing. In this case we used Kurento as a broadcasting server: it received one WebRTC AV stream from a presenter (the video capturing laptop) and retransmitted it via multiple WebRTC streams to viewers.

We ran Kurento on a Linux VM on my laptop. The intention was to test on a VM and then deploy to some cloud service. However, due to lack of time, the debug setup became the production one.

Notes:

After the Stream ended I realized that the VM had exactly 1 core and 1GB of RAM allocated to it. Handled perfectly.
If working from behind a NAT you might also need to setup a TURN and/or STUN servers. Fortunately, the Media Lab’s wired network allocates a public IP to any wired device so the VM used a bridged network and we didn’t have to worry about that.
I later found out that there are some kurento dockerfiles out there for quick containerized deployment of Kurento.

Signaling Server

The signaling server is responsible for serving static assets and connecting the clients with the Media server via WebSockets. Our Node.js server was based on Kurento’s one-to-many video call tutorial and ran on my laptop. When I say based I mean completely copied. The only change we made was to separate the presenter page from the viewing page and completely remove everything besides the video container on the viewer page. here’s the code.

Screenshots of the live viewing page. Notice the change in the favicon.

Notes:

The fun thing about serving files directly from your computer is that you can hot swap them. We were tweaking the viewing experience during the stream, including changing the favicon and various css fixes.
To avoid exposing my personal laptop (signaling was running directly on my computer, not on a VM) we used the ngrok tunneling service.

left: ngrok with 5 open connection. right: printout from the signaling server.

Video Capturing

Tal managed to find a cheap video capture card in the lab (something like this) and a laptop that would actually work with it (ours didn’t). We used Firefox to connect to our presenter endpoint which handled the WebRTC handshake with the Media server.

Notes:

Halfway through the stream I realized that there was no audio feed connected to the capture card and that we’re actually using the laptop’s microphone. Surprisingly, the sound was fairly good.
Of course, it’s far from being a secure solution - anyone could connect to that endpoint and serve as a presenter.

Results

We had a peak of 37 concurrent streams and averaged around 12. Due to time constraints and because the panel was actually quite interesting we didn’t have any continuous monitoring or collected information about load but it sure felt like we could handle a lot more. The machine was responsive (even the VM) throughout the session and I’m still amazed that a tiny VM with no optimizations handled it. KUDOS to Kurento.

Some take aways

When you wait until the last possible minute to do something, it will take exactly one minute. (Parkinson’s Law). If we had decided to do this a week before then it would have taken a week. Of course, the client would be more polished and performance would be tested. But who cares? Sometimes good enough is good enough.
There’s a tool for that. I always thought that setting up live streaming is a lengthy, non-trivial task. We live in an amazing time where the tools are just there and the only thing that limits us is our perspective.
You are a server. In the early days of the internet it was clear that all nodes in the network are created equal. Anyone can consume services and anyone can provide services, whether it’s a Web page or an IRC node. The differentiation between a server and a client is a networking protocol technicality. There is no reason why a node can’t serve both as a client and a server. However, with massive data centers, Cloud computing and NAT, we’ve adopted a model of complete separation, our personal machines are clients and those behind some abstract cloud are servers. Serving anything from your machine, not just for debugging purposes, is part of the spirit of the internet. We should build tools that allow it (thanks ngrok!) and services that take advantage of it.

Thank you Tal Achituv for reminding me all of the above.

Intercepting Cookies in a Chrome extension

Sun, 28 Feb 2016 04:59:59 +0000

Last week I built a Chrome extension that was supposed to solve privacy on the Web. It didn’t - but that’s a different post.

I did, however, find my self in need of intercepting all cookie read/writes in a Chrome extension. This proved to be interesting and non-trivial so here’s a brain dump of the process - hopefully this helps someone somewhere. (and by someone, I’m looking at you, future self!)

Intercepting cookies?

Yup. Some potential use cases:

Managing multiple Cookie stores
Using alternative Cookie stores
Namespacing Cookies
Exposing Cookies on a conditional basis like time, url, etc.
Cookie Art

Generally speaking, an extension will intercept cookies either to save your privacy or to completely violate it. With great power comes great responsibility.

True. And it’s a fine API, yet, it does not allow real-time interception. Meaning, you can read and write cookies and even get notified when cookies change, but not manipulate them WHILE they are being read / written.

OOGI

For the sake of this post I will build OOGI (shorthand for Oogifletset - the Hebrew translation of “The Cookie Monster”) a simple extension that statically namespaces all cookies with the prefix oogi$. When cookies are set they will be prefixed before being written into the cookie store, and when being queried the prefix will be removed - making it completely transparent to remote servers.

The following assumes you have basic knowledge in building a chrome extension and understand what a cookie is. The full source code is available here.

There are two ways to get and set cookies. I’ll tackle each one of them separately:

HTTP Headers
document.cookie

HTTP Headers

The HTTP Request “Cookie” header will contain all cookies currently set and the HTTP Response’s “Set-Cookie” header writes/modifies cookies.

A Request’s “Cookie” header is a concatenation of all cookie names and values for the current domain and path:

Cookie:my_int_cookie=16091; my_double_cookie=0.2545873837079853

A Response can contain multiple “Set-Cookie” headers, one per cookie. These also contain a Path and optionally a timeout:

Set-Cookie:my_int_cookie=5540; Path=/
Set-Cookie:my_double_cookie=0.5358087662607431; Path=/

Luckily, Chrome extensions have a Webrequest API for manipulating HTTP requests and responses in a blocking manner.

Declaring stuff in manifest.json:

{
    ...
    
    "permissions": [
        "webRequest",
        "webRequestBlocking",
        "*://*/*"
    ],
    "background": {
        "scripts": [
            "background.js"
        ],
        "persistent": true
    },
    
    ...
}

The WebRequest API allows us to intercept different stages in the lifecycle of an HTTP Request/Response loop.

Here, in background.js, we plug into onBeforeSendHeaders to modify sent cookies and to onHeadersReceived to modify the setting of cookies:

chrome.webRequest.onBeforeSendHeaders.addListener(
    function (details) {
        details.requestHeaders.forEach(function(requestHeader){
            if (requestHeader.name.toLowerCase() === "cookie") {
                requestHeader.value = processCookieStr(requestHeader.value);
            }
        });
        return {
            requestHeaders: details.requestHeaders
        };
    }, {
        urls: [ "*://*/*" ]
    }, ['blocking', 'requestHeaders']
);

chrome.webRequest.onHeadersReceived.addListener(
    function (details) {
        details.responseHeaders.forEach(function(responseHeader){
            if (responseHeader.name.toLowerCase() === "set-cookie") {
                responseHeader.value = processSetCookieStr(responseHeader.value);
            }
        });
        return {
            responseHeaders: details.responseHeaders
        };
    }, {
        urls: ["*://*/*"]
    }, ['blocking','responseHeaders']
);

The actual cookie string manipulation happens in a separate file. See full code for specifics.

document.cookie

This is the fun part.

Cookies can be directly manipulated with Javascript via the document.cookie property which is a javascript accessor property. If you’ve never encountered accessor properties (like me until a week ago), you’re in for some surprises.

Let’s examine document.cookie in the Chrome dev tools console:

> document.cookie
"my_int_cookie=25760; my_double_cookie=0.563346192939207"

Looks like a String property. right? Let’s try to write a different value.

> document.cookie="A=1"
"A=1"
> document.cookie
"my_int_cookie=25760; my_double_cookie=0.563346192939207; A=1"

So writing to this property actually appends the written value?

> document.cookie="A=2"
"A=2"
> document.cookie
"my_int_cookie=25760; my_double_cookie=0.563346192939207; A=2"

Nope. It seems that the String is only a representation of an actual collection behind the scenes.

So what’s going on here? Accessor properties can be set with custom getter and setter functions. That means that by invoking the property we’re actually calling a getter function and by assigning value, a setter function. These are defined using the Object.defineProperty() method.

Let’s try to use Object.defineProperty() function to override document.cookie:

> Object.defineProperty(document, 'cookie', {
      get: function() {
          return "My amazing getter";
      },
    
      set: function(value) {
          console.log("My amazing setter");
      }
  });
> document.cookie
"My amazing getter"
> document.cookie = 1
My amazing setter
1

Great success! This might suffice if our extension completely ignores Chrome’s internal cookie store. But, if access to the cookie store is still required, which is case for Oogi, we need to save a reference to the original getter and setter functions of document.cookie.

Theoretically, the Object.getOwnPropertyDescriptor() function should help with that.

> Object.getOwnPropertyDescriptor(document, "cookie")
undefined

It seems, however, that Chrome doesn’t want you to access that specific descriptor.

However, We can still use the __lookupGetter__() and __lookupSetter__() functions which are deprecated-do-not-use-or-the-universe-will-implode.

> var cookieGetter = document.__lookupGetter__("cookie").bind(document)
> var cookieSetter = document.__lookupSetter__("cookie").bind(document)
> cookieGetter()
"my_int_cookie=14356; my_double_cookie=0.22253736178390682"
> cookieSetter("A=1")
> cookieGetter()
"my_int_cookie=14356; my_double_cookie=0.22253736178390682; A=1"

Bingo!

However, all of this this experimentation was done in the Chrome dev tools console. How do we port this to our extension?

Running custom javascript code in every webpage is done using content scripts. However, the document object in a content script is actually a replica. Modifying it is not visible to the rest of the Javascript code in the page. Luckily, this is a well discussed issue and the most simple solution is to create a custom script element and inject it into every page.

Declaring our content script in manifest.json:

{
    ...
    "permissions": [
        "contentSettings",
        "*://*/*"
    ],
    "content_scripts": [
        {
            "matches": ["*://*/*"],
            "js": ["content.js"],
            "run_at": "document_start"
        }
    ],
    "web_accessible_resources": ["inject.js"],
    ...
}

Creating a content.js script that injects an external js file:

var headElement = (document.head||document.documentElement);
var injectJs = function(fileName) {
    var s = document.createElement('script');
    s.src = chrome.extension.getURL(fileName);
    headElement.insertBefore(s, headElement.firstElementChild);
};
injectJs("inject.js");

And finally, overriding document.cookie with our injected javascript:

var cookieGetter = document.__lookupGetter__("cookie").bind(document);
var cookieSetter = document.__lookupSetter__("cookie").bind(document);

Object.defineProperty(document, 'cookie', {
    get: function() {
        var storedCookieStr = cookieGetter();
        return processCookieStr(storedCookieStr);
    },

    set: function(cookieString) {
        var newValue = processSetCookieStr(cookieString);
        return cookieSetter(newValue);
    }
});

That’s it!

I left out some of the glue code to keep this post relatively short. You can checkout the complete example here. Feel free to submit issues and pull requests if I missed anything.

Huge thanks to Thariq for helping out with the JS hacking!

A Blog named Blob

Thu, 11 Feb 2016 04:59:59 +0000

Blog? A couple of weeks ago, following the death of Parse.com, I wrote a rant about the virtues of portability and how they are too often overlooked. Posting that rant on a system that inherently does not allow portability (facebook, medium, etc.) felt a bit wrong. So, following a New Year’s resolution to better document my work, a blog seemed in order.

Blob? Developer blogs usually have a wise ass name. This Blob is no different. Some rationalizations:

“an indeterminate mass or shape” : I’m not committing to a specific theme. Tech rant will probably rule but an occasional hummus recipe or fabrication tutorial might appear.
“binary large objects” : Same as above but in geek terminology. Anything can be represented as a binary object.
Yes. Blob sounds like Blog.

Jekyll is a bullet proof, dead simple and open source static site generator. In comes markdown - out comes a static website. The output, being simple html, can be hosted virtually anywhere. As a bonus, github pages will build and host your jekyll website free of charge.

Comments are a bitch. They add dynamic content to an otherwise beautifully static website. The de-facto industry standard is disqus but using that means someone else owns your discussion. It also means user session data is shared and no anonymous comments are allowed. In comes isso - an opensource, self hosted alternative to disqus. I love the idea of having sqlite as a datastore and, let’s face it, the ammout of expected comments (~1 per year) does not justify a multi-connection database solution. I’m running isso on a VM in an undisclosed location in the world…

Design - I’m slowly developing a hatred for beautiful web pages. Everything on the web is just too God damn pretty these days. I decided to get rid of all of Jekyll’s styling and start from scratch. I like fixed width fonts and I’m taking cues from Florent Verschelde’s monospace theme on tumblr and remarkdow css library. My css file is currently 10 lines long but will probably grow when richer content is added. I’m also using a solarized bright css for code highlighting and isso’s default css with minor modifications. UPDATE: Travis pointed out motherfuckingwebsite.com which is spot on.

The code is available here.

Parse is dying - all hail the benevolent dictator

Thu, 28 Jan 2016 05:00:00 +0000

Facebook are closing down Parse and it seems that the developer community is thrilled. After all, they’re letting it die slowly and open-sourcing a parse compatible server. And what if they hadn’t been so nice? Have we gotten to a point where our applications depend on the generosity of 3rd party service providers? Yes. We use gmaps for mapping, Facebook for authentication, Amazon S3 for storage and much more. Some choices are almost unavoidable and some are worth the risk and/or saved resources. However, depending on 3rd party services has become the norm rather than a conscious decision.

Sometimes services get shut down, sometimes pricing changes and sometimes it just doesn’t work as well as it used to / you expected. Dealing with your own bugs and errors is no fun. Dealing with someone else’s is horrific. What can we do? design for portability.

Portability is a major design consideration that is often overlooked. When faced with a technology decision we should give credit to options that allow portability. For example, a hosted mongodb solution (compose, mongolab) allows you to seamlessly move your data between services or to a private mongo installation. Whereas proprietary data stores like the Google App Engine datastore or Amazon’s DynamoDB have you locked in for life or until you manually (and painfully) migrate away.

Sometimes it’s worth it. Some services, such as Amazon’s S3, are so ridiculously good and the portable alternatives are so bad that other decisions just don’t make sense. But it’s still important that we understand the price we’re paying.

On the flip side, and with all due credit, by creating the new open source parse-server, Facebook have just turned Parse into a pretty portable piece of technology. I believe we will soon see multiple Parse-as-a-Service providers that will standardize the young Backend-as-a-Service industry and make it a better option for those of us who still insist of thinking about portability.

Tomer Weller / Blob

ESP32 - first steps

What is the ESP32?

Hardware Setup

Equipment Used

Basic Connectivity

Sanity Check

Programming

FreeRTOS

ESP - IDF

ESP32 ARDUINO CORE

Ring Oscillator benchmark

More Resources

Thanks:

Clojurescript/Reagent : importing React components from NPM

Motivation

Why not Cljsjs?

Zefstyle

NPM Setup

package.json remarks:

Webpack setup

Leiningen project setup

Grand finale

Caveats:

Thanks to:

Setting up a free live streaming solution in two hours

Note: a previous version of this post had some licensing terminology issues. This post discusses Free software.

The Setup:

Media Server

Signaling Server

Video Capturing

Results

Some take aways

Intercepting Cookies in a Chrome extension

Intercepting cookies?

Isn’t there already a Cookie API for Chrome extensions?

OOGI

HTTP Headers

document.cookie

Huge thanks to Thariq for helping out with the JS hacking!

A Blog named Blob

Parse is dying - all hail the benevolent dictator