Bloomberg ran the headline: “Anthropic AI Tool Sparks Selloff From Software to Broader Market.”

So I went and read what Anthropic actually shipped.

What Anthropic Actually Released

On January 30, Anthropic open-sourced eleven plugins for Claude Cowork, their agentic desktop app. One of those plugins was for legal work — six subdirectories of plain text files: contract-review, nda-triage, compliance, legal-risk-assessment, meeting-briefing, and canned-responses.

No new model. No API. No product launch. A GitHub repo with ~2,500 lines of structured prompt instructions. The kind of thing thousands of developers write every day when building on top of LLMs.

Here’s the core of the contract review methodology, quoted directly from the repo:

1. Identify the contract type: SaaS agreement, professional services, license, partnership, procurement, etc.
2. Determine the user’s side: Vendor, customer, licensor, licensee, partner.
3. Read the entire contract before flagging issues. Clauses interact with each other.
4. Analyze each material clause against the playbook position.
5. Consider the contract holistically: Are the overall risk allocation and commercial terms balanced?

That’s the review process. The entire methodology. Identify, determine sides, read, analyze, consider holistically. This is what a law school student probably learns on day one.

First-Year Law School Material

The NDA triage skill is a 10-point checklist: agreement structure, definition scope, obligations, standard carveouts, permitted disclosures, term, return/destruction, remedies, problematic provisions, governing law. Every in-house legal team has this document pinned somewhere. The green/yellow/red classification system is a standard risk matrix — the same framework taught in corporate legal training.

Don’t get me wrong: The prompts are well-crafted. But: They’re not magic. They’re structured instructions for tasks that legal professionals have been doing for decades. And they’re open source — anyone can read them, copy them, modify them. You can run them in OpenAI. Or an Open Source Model like DeepSeek.

There is no competitive advantage here that couldn’t be replicated by a competent developer in an afternoon.

The Information Asymmetry Is the Story

The repo is public. Anyone could have read it in 10 minutes. The market priced in fear of something that’s fully auditable on GitHub. That gap between perception and reality is the actual story.

So $285 bn lost — not because of a product launch, but because of a markdown file in a GitHub repo. Investors didn’t click through. They didn’t read the prompts. They didn’t ask a single engineer what a “skill plugin” actually is. They saw “Anthropic” and “legal” in the same sentence and hit sell.

This isn’t an AI disruption story. This is a market literacy story. The selloff tells us nothing about AI’s impact on the legal profession and everything about how poorly the market understands what AI companies actually ship.

What This Actually Tells Builders

Anthropic published these prompts freely because the prompts aren’t the product.

The “moat” for vertical AI isn’t prompt engineering — it’s execution, trust, integration, compliance, and liability acceptance. Anthropic just demonstrated that by giving the prompts away. What does that tell you about every “AI wrapper” startup whose entire value prop is a system prompt?

The Real Question

AI will reshape law firms, consultancies, and half the NASDAQ. That’s not controversial. The “software eating software” thesis has been in every VC deck since 2023. Claude Code, Cursor, Codex — they all exist. Nobody disputes the direction.

So why did a GitHub commit containing first-year law school content trigger a $285 billion repricing? Either the market hadn’t priced in something that’s been “obvious to everyone” — meaning it wasn’t actually obvious to investment professionals — or they overreacted to a headline without reading the repo. Both are equally frightening.

And here’s the kicker: this repo is public. If the people managing your money can’t do due diligence on something freely auditable on GitHub, what are they diligencing behind closed doors?

If your investment thesis can be wrecked by a README file, maybe the thesis was never there to begin with.

Because DynamoDB access is essentially all network I/O over HTTPS, it is a good playground to tinker with Ruby fibers before bringing the same approach into other production systems.

Airfield Directory runs on Falcon because I want fiber-based concurrency without the memory overhead of thread-per-request. It should feel fast and smooth under load.

Then the dynamic map happened.

The map view fans out a lot of DynamoDB queries across H3 hexagonal grid cells (a system invented by Uber). Under Falcon, I expected those requests to overlap in fibers. Instead, the reactor stalled and the app behaved like it was single-threaded again: latency spikes, janky scrolling, that “it’s fast until it isn’t” feel.

My first instinct was to do what I do elsewhere (e.g. ruby_llm): wrap the hot path in Async { ... } and trust the scheduler. It didn’t help. The AWS SDK was still blocking the reactor.

Trying to explain why the AWS SDK for Ruby fights Falcon

The AWS SDK’s default HTTP transport uses Net::HTTP wrapped in a connection pool. Contrary to what you might expect, Net::HTTP itself is fiber-friendly in Ruby 3.0+—the fiber scheduler hooks into blocking I/O and yields to other fibers automatically.

But in practice, those implicit hooks don’t yield reliably, so the single reactor thread gets blocked often enough that all fibers serialize.

What I actually saw in production:

barrier = Async::Barrier.new(parent: parent_task)
batch_cells.each { |id| barrier.async { dynamodb.query(...) } }
barrier.wait

-> Observed: serialized request time

threads = batch_cells.map { |id| Thread.new { dynamodb.query(...) } }
threads.each(&:join)

-> Observed: 1× single request time (concurrent)

So my current observation/explanation is:

• The SDK’s Net::HTTP transport is synchronous end‑to‑end and relies on implicit scheduler hooks in Net::HTTP/OpenSSL/DNS.
• In our workload, that path blocked the reactor often enough that the Async::Barrier output serialized.
• Threads still overlapped because each call ran in its own OS thread. Swapping the transport to async‑http fixed it because async‑http is fiber‑native end‑to‑end (pool + I/O), so the reactor can actually interleave requests.

I can’t tell you in detail whether it’s gaps in hook coverage, OpenSSL handshakes, DNS resolutions, whatever … In the end, async-http seems to me to be by far the best solution in the whole Async ecosystem. Of course, there might be other side effects I have overlooked, but in the end was/is my real-life observation reproducable.

I eventually fell back to threads just to keep the UI responsive. It worked, but it felt wrong.

I dug through the SDK internals and landed on the same conclusion captured in this issue: https://github.com/aws/aws-sdk-ruby/issues/2621 and an abandoned experimental repo.

So, in a nutshell:

• Threads overlapped because each call ran in its own OS thread.
• Fibers with Async::Barrier serialized under Falcon.
• Swapping the transport to async-http fixed it—because async-http is fiber-native end-to-end (pool + I/O), most likely because the reactor can actually interleave requests.

The solution: aws-sdk-http-async

I built a new HTTP handler as a gem plugin for aws-sdk-core using async-http called aws-sdk-http-async. It aims to preserve the SDK’s semantics (retries, error handling, telemetry, content-length validation), but make the transport fiber-friendly under Falcon.

Key goals:

• Async transport when a reactor exists (Falcon).
• Automatic fallback to Net::HTTP when no reactor exists (rake/console/tests).
• No patches required to make CLI tasks work.
• Safe defaults, explicit config, and clear failure modes for event streams.

Usage (zero-config)

Add it to your Gemfile:

gem 'aws-sdk-http-async'

More information in the repo on Github

AI Promises vs. Reality

Pitch decks are dazzling, promising AI marvels and tales of wonderlands. But when our team of CTOs at Expedite peeks under the hood, we often find the AI is more “artificial” than “intelligent.” When it comes to the moment of truth and we check the code, it’s often just a fancy facade for simple algorithms. It’s like expecting a Tesla but finding a remote controlled toy car instead.

Together with my fellow co-investor, Sebastian, a machine learning wizard for years, we’ve seen a lot in 2023: Take some recent pitches we examined, promising groundbreaking AI for data extraction. Spoiler alert: behind the AI mask was just basic coding without a whiff of AI insight. We’ve looked at code and models and yet, all we found was a straightforward hardcoded approach, without a hint of AI or ML.

We’re noticing a pattern: startups are in love with the AI label (sometimes rightly so when you look at the insane valuations paid for often lousy tech), and even when they incorporate some AI components, their data sets are often as thin as air. Even more often we’re just seeing a wrapper for the ChatGPT/OpenAI API. While there’s nothing wrong with that in a prototyping phase, it helps to point that out from the beginning. Also, we’ve noticed that the mindset of ‘just quickly using the API, we’ll change that later’ can hinder the accumulation of know-how in building, training, and operating customized models (which should be the goal if you’re an ‘AI Startup’, right?). Intriguingly, this approach often leads to a rapid burn rate — a hint: sometimes even unnecessary in the era of LLAMA.

While we definitely don’t claim to have all the answers or see every AI startup on the planet, the hundreds of pitches we reviewed in 2023 revealed a distinct pattern we can’t ignore.

In short: Big AI dreams, sure, but the tech isn’t walking the talk. If we had received a chocolate bar for every time we’ve seen a rules engine sold as AI, we would have had to skip Christmas this year.

A Call to Startups

Dear startups, let’s keep it real. If your AI is more of a future plan than a here-and-now reality: just say so. It’s cool to be a work in progress. Pretending otherwise? Not so much.

Investor Colleagues - look beyond the AI Sparkle

Fellow investors, don’t get lost in the AI fairy dust. Dive deep, ask hard questions. Look beyond the shiny surface of pitch decks brandishing the ‘AI’ label (means, about 95% of all pitch decks we get these days). At Expedite Ventures, we’re all about finding the genuine tech gems hidden in the AI noise. And we’re more than happy to lend a magnifying glass.

Final Thoughts

Innovation is more than a buzzword. It’s about bringing real, groundbreaking tech to the table. In the end, it’s about genuine innovation, not AI fantasies. We’re on a mission to find startups that truly push tech boundaries, not just play dress-up with buzzwords. Many AI startups lose their shine under a tech-savvy gaze. Remember, it’s not just about joining the AI parade; it’s about leading it with substance.

Let’s champion the real tech heroes — the ones who are honest about their journey and potential. Here’s to investing in solid ground, not just AI castles in the cloud.

P.S.:This isn’t just about critique; it’s about building a stronger, more genuine tech ecosystem. And hey, at Expedite Ventures, we’re always on the lookout for the real tech magicians. Got an honest, groundbreaking idea? We’re all ears!

The Wise API documentation is adequate, though occasionally lacking in detail. Also, at least in the EU, downloading balance statements requires two-factor authentication, not just a simple API call. This process involves making an API call, receiving a challenge, signing it with an RSA certificate, and then reissuing the request. Although it’s not complex, it took some time to perfect.

I created a user-friendly script that prompts for your Wise personal API token, account selection, statement year, and currency.

Setting this up requires a few steps. I recommend a trial run with a sandbox account at https://sandbox.transferwise.tech/. You’ll need to create an API token with read-only access and back it up securely. Additionally, generate a public key using the following commands in a cloned GitHub repository.

Step-by-Step Guide to Creating a Wise API Token and 2FA Public Key

To set up your API keys, first go to “Settings” and then to “API tokens”:

• Create a personal API token in Wise
• Click “Add new token”:

• Add a new token in Wise.com
• Read Only Access for the new token is sufficient:

• Read Only Token for wise.com API

In addition to backing up the token in a password manager, you will also need to generate a public key. The most convenient way to do this is by cloning my GitHub repository containing the script and creating the key directly within that environment:

git clone https://github.com/thomaswitt/wise-statement-downloader.git
cd wise-statement-downloader
mkdir certs
openssl genrsa -out certs/wise-private.pem 2048
openssl rsa -pubout -in certs/wise-private.pem -out certs/wise-public.pemMake sure you’ll also backup the newly created RSA key.

That’s essentially all there is to it. After completing these steps, you can run the script to easily obtain your first account statement:

thomas@mac:~/Dev/wise-statement-downloader(main) $ ./wise.bash test
*** Using Sandbox API Environment
WISE Personal API Token: [CONCEALED]
Choose account:
1: Esmeralda Beasley (2023) (17012841)
Your choice: 1

Choose year for the statement:
1: 2023
Your choice: 1

Choose currency:
1: AUD (1000000.00 AUD) (179137)
2: EUR (1000000.00 EUR) (179096)
3: GBP (1000000.00 GBP) (179136)
4: USD (1000000.00 USD) (179097)
Your choice: 2
Chosen currency: EUR

*** Writing PDF file to output/Wise-17012841-Esmeralda\_Beasley-EUR-2023.pdf

The script currently supports downloading annual statements, but it can be easily modified for monthly intervals by adjusting the $STATEMENT_DETAILS variable.

Now just repeat these steps in your main production account — and you’re good to go.

Enjoy the convenience!

I created a script for my .bash_profile or .zshrc (works both via bash and zsh) to track new, unwanted additions. It doesn’t automatically delete these items but provides removal commands every time I open a shell, which is frequently. Of course, you could also automatically remove them if you don’t want to manually double-check.

Notice: This script does not affect Login Items (accessible through System Preferences > Users & Groups > Login Items), where applications can be set to launch at startup and also install background daemons (often for AppStore-based Apps). Additionally, I created an alias to monitor these via the command line as well (show_background_tasks).

Enjoy!

#!/usr/bin/env bash

# Remove unwanted helpers
process_agents() {
  local directory=$1
  shift
  local agents=("$@")
  local pattern=$(
    IFS=\|
    echo "${agents[*]}"
  )
  shopt -s nullglob
  for plist in "$directory"/{LaunchAgents,LaunchDaemons,PrivilegedHelperTools}/*; do
    if [ ! -s "$plist" ]; then continue; fi
    if ! echo "$plist" | egrep -q "^.*Library.*/($pattern)"; then
      local plist_name=$(basename "$plist" .plist)
      if [[ $directory = /Library* ]]; then
        echo "sudo bash -c 'launchctl disable system/$plist_name && true > \"$plist\" && chmod a-wx \"$plist\"'"
      else
        echo "bash -c 'launchctl disable gui/$(id -u)/$plist_name && true > \"$plist\" && chmod a-wx \"$plist\"'"
      fi
    fi
  done
}

# Define global and local agents to manage
global_agents=(
  at.obdev.littlesnitch         # Little Snitch
  com.docker                    # Docker
)
process_agents "/Library" "${global_agents[@]}"

local_agents=(
  homebrew.mxcl.ollama        # ollama
  jp.plentycom.boa.SteerMouse # SteerMouse
)
process_agents "$HOME/Library" "${local_agents[@]}"

# vim: filetype=bash:

And this is exactly what our portfolio company Supernova does — in this case it’s bridging the gap between designers and developers. The connection between those two is an extremely important one in the world of ever-more important UX — and still, the disconnect sometimes couldn’t be bigger, particularly in larger organizations. And that leads to broken, inconsistent user experiences — because it’s simply hard to manage and update a consistent design over its complete lifecycle.

Supernova actually helps designers and developers to work better together in the context of a so-called design system. Those have become the hot topic in the recent years. A design system is a shared language, a set of standards to create beautiful visual experiences, based on reusable components and patterns. It’s the final source of through about the design language of a company. At scale.

Supernova helps managing and documenting the entire lifecycle of a Design System centralized in one place without changing workflows or tools like Figma.

For a developer that means if a refinement of a design is to be rolled out, you’ll get an automated export delivery of tokens, styles, assets and code to handover to the developers. So your flutter-based mobile apps will get the same updates like your website, and developers get everything served on a silver plate in form of a GitHub pull request. Cool, eh?

And that kind of cooperation doesn’t only make the designers and developers happy, but also the management of a company. Because they get not only higher quality through visual consistency across multiple products and channels, they’ll also save a ton of money. That’s why they keep on convincing more and more large name brands. And with their latest announcement of their design token manager with support for Figma Tokens plugin and themes, they’ll continue to lead the space for Design Systems.

That’s why we are incredibly excited and honored to partner with the Supernova in their $4.8m seed round. Congratulations to Jiri, the Founder and the whole team. We are looking forward to the journey ahead!

Of course, we at Expedite will continue to keep investing in great DevTools to make developers and companies more productive and successful.

Further Reading:

• Supernova.io Homepage
• Blog post by Jiri, Founder of Supernova
• TechCrunch: Supernova wants to make it easy to move design elements to code bases

You might be familiar with that situation: You’re at a coffee shop, and airport or wherever and want to connect to a WiFi.

But once you do so, your iOS device starts broadcasting data over that insecure network, for example with apps which are using background refresh. Things get worse when you fire up your web browser and browse on insecure http-Sites.

Congratulations, you just made yourself a target for hackers (and your device will be automatically equipped with Malware). At least anyone on the network can trace which sites you are connecting to. And worse, your iPhone will still continue to broadcast data over this insecure connection, even when it’s on standby in your pocket or it reconnects to a forgotten WiFi-Network you once signed on.

Danger #1 to IT security is connecting to the Internet via public WiFi. Don’t be tricked to think that’s a problem only existing in shady internet cafes: Criminals have been targeting business travelers in Asia in 5* Hotels since at least 2009. Similar things were reported about Russia.

Wherever it is, it can happen everywhere around the world, as soon as you connect your device to an unknown WiFi network. The tools are widely available, and it’s a matter of minutes to manipulate networks, intercept connections in order to to take over your unpatched computers with malware or steal passwords (online banking, anybody?).

There might be even whole countries (China, anyone?) where you want to use your connection always with over a VPN enabled, because most web-sites and service won’t reachable anyway.

So in general: you always want to use a VPN (except in your WiFi network at home maybe) — and in an ideal world you want to make sure that no single byte is transferred without an active VPN when connecting to a WiFi network. This is called an OnDemand VPN.

On the Mac I highly recommend to use Little Snitch and its profile functionality to achieve exactly that (I’ve wrote an article about Internet security while traveling before). On iOS devices, it’s unfortunately not that straightforward.

Luckily, iOS devices like iPhones and iPads have a functionality built in which allows you to do exactly that: Always connect to a VPN except for certain WiFi networks. Unfortunately it’s only achievable throught a so called profile, which you have to install manually on your phone — and there’s no graphical user interface to create such an sophisticated OnDemand profile. So you have to use your text editor.

So what I did is, I created an easy-to-install profile which gives me access to three different VPN options:

• An IPSec connection to my home router (a FRITZ!Box), so I can connect to my home network (especially useful if you’d like to connect to firewalled devices such as webcams)
• An L2TP conncetion to our company network router (a Cisco Meraki)

• An L2TP connection to an Streisand powered VPN at Amazon Web Services — if you’re not familiar with Streisand, it’s an open source tool which creates a cheap AWS EC2 instance with all kinds of way to access it as a VPN. This is also my default profile, because AWS obviously has the highest data throughput. For each of these three VPNs I created three options:

• Always: Always connect to this VPN, regardless whether you’re on Cellular or WiFi and regardless of the WiFi network. That’s the most secure option.
• WiFi: Only connect to this VPN when you’re an WiFi and if the network name isn’t from a specific set of WiFi network names (so you won’t use VPN at home or in your company).

• Manual: Never automatically connect to a VPN, unless you switch it on manually. That’s your backup, in case you NEED to connect but everything is blocked. The following profile does all of that. To use it, you have to perform the following steps:

• Get rid of the sections you might not need.
• Change the passwords, usernames and shared secrets to your personal access credentials (look out for CHANGEME).
• Change the SSIDMatch strings in the WiFi profile to your WiFi network names you’d like to exclude from the VPN-obligation.
• Save this text file as VPNConfigurationProfiles.mobileconfig (the suffix is important).
• Upload the profile via AirDrop to your iPhone or iPad (you have to enter your device passcode to install). I usually leave my devices at “AWS: WiFi”. So at home, I’m surfing without a VPN, same applies to any cellular connections, but whenever I connect to a WiFi, my Streisand AWS VPN is used.

What are the downsides? Not many. There might be some strange WiFis with a splash page, which is not correctly recognized by your iOS device as such. So the VPN tries to connect but gets blocked because you haven’t confirmed on the splash page. So either you don’t use the WiFi or switch to manual, confirm the splash and switch back to the original WiFi VPN profile. Needless to say, that’s not perfectly secure.

You can actually set even more options in the profile, such as limiting VPN usage to certain domain names or to certain apps. You’ll find all parameters in the (very long) Configuration Profile Reference documentation at Apple.

So stay safe and always use a VPN — here is the profile.

Update

Check out Kris cool generator for profiles: https://t.co/e5QU6Hb7Dl

We’re using Geckoboard to cloud-power our dashboard. It’s only $25/month and it includes great functionalities. They offer you a lot more out-of-the-box than you could manually build for 25 bucks. So get an account and sign up.

But having a great dashboard only brings you so far — the question is, how to visualise it. We’ve already got a lot of TV screens in every room (which are powered by AppleTVs and AirPlay, so we don’t need any HDMI cables).

So we looked for a cheap, reliable and easy solution to display our dashboards on these screens. And what could be better suited as a Raspberry Pi 3.

Of course you don’t want to spend a lot of time to manually set up a dashboard — and you’d like to display it automatically in full screen on your beautiful HD display.

So here’s our recipe how we set up our Raspberry Pi’s for Geckoboard. It only takes about 10 minutes.

SD card preparations on your Mac

Find out using Disk Utility.app or diskutil list, which /dev at device your SD card is mounted. Mine mounts usually at rdisk2, so first download the package, unzip it and transfer it to the SD card:

wget
[https://downloads.raspberrypi.org/raspbian_latest](https://downloads.raspberrypi.org/raspbian_latest)
unzip
raspbian*latest # and insert SD using an adapter into MBPdiskutil unmountDisk
/dev/rdisk2
dd bs=1m if=2016-09-23-raspbian-jessie.img of=/dev/rdisk2
diskutil eject /dev/rdisk2

Pro tip: After the installation is done, you can again clone the SD card using _dd*, copy it to more SD cards and effectively cloning your Pi.

Remote Installation via ssh

Hook up your Pi via Ethernet to your network, find out its IP and do the rest of the installation via SSH and change your password immediately (Tip: Use 1Password to create and store secure passwords):

ssh pi@<ipaddress> # password: raspberrypasswdFirst of all you should create an
ssh directory and upload your ssh keys, e.g.:

mkdir .ssh
cat >.ssh/authorized_keys <<EOF
ssh-ed25519 ssh-ed25519 AAAAC\_\_REPLACE_WITH_YOUR_KEY\_\_pm4tj56K87GzrK
EOFBackup the autostart file and replace it with your own so that Chrome boots
up straight when booting the Pi (change your URL to your
[Geckoboard sharing URL](https://support.geckoboard.com/hc/en-us/articles/202333706-Sharing-a-dashboard-Secure-sharing-links-)):

cp .config/lxsession/LXDE-pi/autostart
.config/lxsession/LXDE-pi/autostart.distcat >.config/lxsession/LXDE-pi/autostart
<<EOF
@chromium-browser --kiosk --disable-overlay-scrollbar --noerrdialogs
--disable-session-crashed-bubble --disable-infobars
<https://mycompany.geckoboard.com/dashboards/YOUR\_URL>
@unclutter -idle 0
EOF

If you’ve got a fixed IP internet connection, you might want to set up IP restrictions to access the dashboard in your Geckoboard configuration.

Afterwards we’ll secure the system, update to the latest package versions and install some convenience stuff:

sudo su -passwd # Change to your new root passwordapt-get update -y ; apt-get dist-upgrade -y ; apt-get autoremove -yapt-get install x11-xserver-utils unclutter ttf-mscorefonts-installer x11vnc xterm vim screen dnsutils rcconf silversearcher-ag mlocate

Then start raspi-config and do some basic configuration:

• 7 Advanced Options > A2 Hostname > dashboard (or whatever)
• 3 Boot Options > B1 Desktop/CLI > B4 Desktop Autologin
• 4 Intl Options > I1 Change Locale (I usually disable en_GB using the space key, enable en_US.UTF8, fallback C.UTF8)
• 4 Intl Options > I2 Change Timezone (in our case Europe/Berlin)
• 4 Intl Options > I4 Change Wi-fi Country (in our case DE — Germany)
• Reboot now After rebooting, your dashboard should already show a Geckoboard screen. It still looks ugly, has scrollbars and no fullscreen, but no worries, we’ll get there in a moment!

I’ve got some convenience dotfiles including aliases in bashrc and my vimrc. I can’t live without these — you might have your own version of your preferred bashrc file, feel free to skip this step:

sudo su -curl -so /etc/bashrc.local
<https://raw.githubusercontent.com/thomaswitt/dotfiles/master/etc/bashrc.local>
echo
"test -e \"/etc/bashrc.local\" && . /etc/bashrc.local" >>/etc/bash.bashrccp
/etc/vim/vimrc /etc/vim/vimrc.dist
curl -so /etc/vim/vimrc
<https://raw.githubusercontent.com/thomaswitt/dotfiles/master/etc/vimrc>

Now we’re going to harden the ssh daemon: No root login, only secure ciphers, etc. — Do not skip this step! Security is important!Make sure that you’ve uploaded your ssh key before and tested in a new shell that your ssh login is still working. Otherwise you’ll lock yourself out from your Pi.

cp /etc/ssh/ssh_config /etc/ssh/ssh_config.dist
curl -so /etc/ssh/ssh_config
[https://raw.githubusercontent.com/thomaswitt/dotfiles/master/etc/ssh/ssh_config](https://raw.githubusercontent.com/thomaswitt/dotfiles/master/etc/ssh/ssh_config)cp
/etc/ssh/sshd_config /etc/ssh/sshd_config.dist
curl -so /etc/ssh/sshd_config
<https://raw.githubusercontent.com/thomaswitt/dotfiles/master/etc/ssh/sshd\_config>
| grep -v AllowUsers >/etc/ssh/sshd_config
echo "DebianBanner no" >> /etc/ssh/sshd_config/etc/init.d/ssh restart# Remove
some annoying messages and replace by a security warning
true >/etc/motd
curl -so /etc/issue.net
<https://raw.githubusercontent.com/thomaswitt/dotfiles/master/etc/issue.net>

Let’s now fine-tune the X11 config that the screen doesn’t go blank, the cursor doesn’t show and we’re going to have a nice HDMI display:

cat >/etc/xdg/lxsession/LXDE-pi/autostart <<EOF
@lxpanel --profile LXDE-pi
@pcmanfm --desktop --profile LXDE-pi
@xset s off
@xset -dpms
@xset s noblank
@sed -i 's/"exited_cleanly": false/"exited_cleanly": true/'
~/.config/chromium/Default/Preferences
EOFcp /etc/lightdm/lightdm.conf /etc/lightdm/lightdm.conf.dist
sed -i 's/#xserver-command=X/xserver-command=X -s 0 dpms/'
/etc/lightdm/lightdm.confcp /boot/config.txt /boot/config.txt.dist
sed -i 's/#hdmi_force_hotplug=1/hdmi_force_hotplug=1/' /boot/config.txt
sed -i 's/#disable_overscan=1/disable_overscan=1/' /boot/config.txt
sed -i 's/#config_hdmi_boost=4/config_hdmi_boost=4/' /boot/config.txt

Then we’d like to check whether our network is already available at boot in order to avoid annoying Chrome error messages:

cat >/boot/IPCheck.py <<EOF#!/usr/bin/env python
import socket
from time import sleepdef checknetwork():
 ip = False
 try:
 s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
 s.connect(('google.com', 0))
 ip = s.getsockname()[0]
 s.close()
 except socket.error:
 return False
 else:
 return ipdef main():
 x = checknetwork()
 while x == False:
 print "Checking network ..."
 x = checknetwork()
 sleep(1)
EOF
chmod +x /boot/IPcheck.pycp /etc/rc.local /etc/rc.local.dist
sed -i 's/# By default this script does nothing./\/usr\/bin\/python
\/boot\/IPcheck.py/' /etc/rc.local

We’re nearly there. Additionally, we’re blanking our screens at night in order to save some energy:

cat >/usr/local/bin/screen.sh <<EOF

# !/bin/bash

if [ \$# -lt 1 ]; then
 echo "Syntax: \$0 (on|off)"
 exit
fi

if [ \$1 == "on" ]; then
 tvservice -p
 sleep 2
 chvt 6 && chvt 7
 echo "Switched HDMI on"
fi

if [ \$1 == "off" ]; then
 tvservice -o
 echo "Switched HDMI off"
fi
EOF
chmod +x /usr/local/bin/screen.shcrontab <<EOF
0 19 \* \* _/usr/local/bin/screen.sh off >/dev/null
0 8_ \* \* /usr/local/bin/screen.sh on >/dev/null
EOF

That’s it. Let’s reboot one last time:

rebootr … and your dashboard should shine! Happy dash-boarding!

Additional notes

If you’d like to use the WiFi of the Raspberry Pi 3 instead of ethernet, the configuration works like this:

sed -i 's/iface wlan0 inet manual/iface wlan0 inet dhcp/'
/etc/network/interfaces# Change SSID, PSK and country
cat >/etc/wpa_supplicant/wpa_supplicant.conf <<EOF
country=de
network={
 ssid="YOUR_WIRELESS_NETWORK_NAME"
 psk="YOUR_WIRELESS_NETWORK_PASSWORD"
 proto=RSN
 key_mgmt=WPA-PSK
 pairwise=CCMP
 auth_alg=OPEN
}
EOF

If you need a terminal, e.g. to copy/paste login information:

x11vnc -usepw -forever -display :0 # choose password
export DISPLAY=”:0”
xterm

Open the connection on your Mac via:

open vnc://HOSTNAME.local

When I found that some people did some research on this topic and found out, that the machine is completely remote-controllable through this (undocumented) port -which is a 9600bps serial interface-, I thought I’d solve a first-world problem which always annoyed me: After I wake up and go to the kitchen, I’ll have to wait until the S95 has warmed up, until I can make coffee.

So on a rainy sunday, I thought I’d automatize this and integrate the S95 into my Siri Homekit setup.

I needed the following parts:

• An Arduino Uno Wifi
• A Raspberry Pi 3 running the Siri Homekit Emulation Homebridge
• A four-pin 2.54mm connection cable for the service port And here we go. First of all, I have to say, that as much as I love Arduino, the Arduino Uno Wifi is the worst documented product I’ve ever bought. I’ve spent a considerable amount of time in figuring out libraries near-to-nonexistant documentation which only consists of a few examples.

But after a while, I’ve figured out how it works. Of course, if you’ll try that at home, that’s at your own risk, this description comes without any warranty. If you’ll send the wrong commands to the S95 or connect the wrong wires, you might very well destroy your Arduino and your S95. So be careful.

Part 1: Arduino Uno Wifi

After you connect the Arduino Uno Wifi to a power source, it’ll automatically create a WiFi network.

You’ll have to log onto that network and configure the connection to your home network via a browser (set hostname, DHCP, etc.).

After that, you’ll have to upload the Coffemaker.ino sketch I’ve uploaded to a GitHub repository:

https://github.com/thomaswitt/CoffeeMakerThis sketch turns the Arduino into a REST server for the coffee maker. Clone the Repo and upload the sketch to the Arduino Uno Wifi using the standard IDE for the Mac:

Part

2: Connect the Arduino to the S95

That’s pretty straightforward. Use the cable mentioned above and plug it into the S95 service port. S95-Pin 4 is on the left, S95-Pin 1 on the right.

We don’t need Pin 4 and the rest connects as follows:

• S95-Pin 3 connects to Arduino Pin #3
• S95-Pin 2 connects to Arduino GND
• S95-Pin 1 coneects to Arduino Pin #2 That’s it. I’ve soldered a pin at the end of the connection cable to make a better connection to the Arduino and isolated it with Heat-shrink tubing.

After you’ve powered your Arduino, you should be able to test the connection using your command line (or simply your browser):

curl <http://ARDUINO.IP.ADDRESS.HERE/arduino/custom/turn\_onshould> turn on the S95 and

curl <http://ARDUINO.IP.ADDRESS.HERE/arduino/custom/turn\_offturns> it off. Besides turn_on and turn_off the commands flush and make_coffee are supported as well.

Go ahead and try it, it should work by now — or you’ll have to go for some debugging. You can also use hostname.local instead of the IP address in the curl request.

Part 3: Connecting Homebridge to the Arduino

Homebridge is an Open Source reverse-engineered implementation of Apple’s Homekit, which allows you to integrate custom stuff into Siri. I’ve installed it on my Raspberry Pi 3, straightforward after installing the newest Jessie-Version of Raspbian Linux, following the installation docs for the Pi and running it on boot-up using systemctl.

After that has been done, you’ll have to install just have to install the homebridge-http plugin on your Pi:

npm install -g homebridge-http

After replacing the standard homebridge config.json configuration with my homebridge configuration you’ll have to restart the homebridge server:

systemctl restart homebridge

Part 4: Ask Siri to turn on the coffeemaker

Now you should be able to start your iOS 10 “Home”-App on your iPhone, and you can add the new Homebridge Pi Server as a new device. Use the standard code 031–45–154 (changeable in the config.json) and you’re good to go by saying “Hey Siri, turn on the coffeemaker!” (or in my case, in german):

Video of remotely controlling a Jura Impressa S95 Coffee Maker with Siri via Homekit and Arduino

That’s it.

What’s currently missing is a status report back to HomeKit about the current status of the machine. That’s unfortunately not so easy as there’s no documentation about the internal status codes of the S95.

If you figure something out regarding the status codes, let me know!

Frankly, I don’t understand why interviews are nowadays appearently done the way they are done. This reminds me a bit of high school, when you had to learn a lot of useless stuff just for the sake of it. Especially in the fast-changing tech world that’s superfluous. If I need a certain algorithm, I just look it up. That’s what the Internet is there for, right? Knowing it out of the blue is great and maybe important for 1% of super algorithm-heavy jobs, but definitely not for the majority of programming jobs. And particularly not for a front-end developer.

I definitely prefer interviews the informal way, like you described your first interviews at Vimeo. I’m interested in the experiences people had and how they learned new things. A good programmer can (and has to) definitely always learn any new stuff, so I’m rather interested in how curious people think, their ability to learn stuff in the future and not what they already know. I definitely don’t believe in some strange whiteboard exercises (which maybe the interviewers wouldn’t pass themselves). If you’ve got your fine projects on GitHub and I can take a look at them, I know that you know how to code.

I’m also a bit astonished of the complete lack of any social compatibility questions in the interviews you’ve experienced. In my opinion, the “how-does-a-person-fit-into-the-team”-Question is at least equally important as the technical skills.

At Scrivito, we’re only doing one round of interviews (if the person can’t visit us in our office, we do a Google Hangout beforehand), usually with me and a senior developer plus a person from HR. After doing the interview in an informal setting where we talk about your experience, your past projects and how you solved problems so far, you know whether the person is generally capable or not. Generally it’s a good idea to trust your gut in that regard.

After the interview everybody who took part has a veto right against the candidate. You don’t have to bring detailed reasons, a “I don’t have a good feeling with this one” is usually enough because it’s almost certainly right.

If everybody has a good impression after the interview, we invite the candidate simply to work a day together with our development team on their everyday’s work. After this day, you usually know not only whether the person is technically capable but more importantly whether he fits into the team.

And also the other way round. Does she want to work with us? I think, a job interview is definitely also a two-sided question. She’s applying at us, but we’re also applying at her. Or at least that’s the way it should be.

At the end of the day, the question is always to the team: Would you like to work with this person or not? And besides all the technical qualification, this is the most important question to form a great team of people who actually like to work together. So if anyone in the team has objections, we don’t hire.

So the finally hiring decision is usually not made by me or HR; it’s the team.

This technique served us very well — and we were generally right with our decisions in 99,9% of all cases. The result is that we’re having really a world class team of developers working on our products, which I am really proud of.

As a rule of thumb, we try to keep our interview process in a way, that a) we’d still like to apply at our own company and b) would still hire ourselves.

Or to quote Elon Musk:

My biggest mistake when hiring is probably weighing too much on someone’s talent and not someone’s personality. I think it matters whether someone has a good heart.I couldn’t have said it better.

Let’s hope Eric, Sergej and Larry can write maze solving algorithms on a whiteboard.