My posts tend to either be super long, filled with tons of pictures, or both. I’m going to try something new. For the next few weeks, I’m going to try exclusively posting from my phone which should help break up content a bit as well as keep it on the shorter side. The first series I do will cover the Fjallraven Classic USA, a 30 mile backpacking trip along the Colorado Trail that starts tomorrow. If you’re curious, Beau Lebens did a pretty thorough writeup of it last year.
Last weekend we headed down into the Canyonlands in Utah. It is one of my very favorite places to be and one of the most pristine environments I have experienced. Where we went is definitely the road less traveled. In fact, it’s impossible to get to for most vehicles. Usually, it’s super photogenic, but it was cloudy the majority of the time. I still took a ton of photos, but I thought I’d try making them black and white. I did save some good color photos for the end, though (and a couple crazy videos).
And here are some of the color photos that were just too good to desaturate.
Here’s a video of our last camp sight. It was quite a doozy. (And we had to be super cautious at night.)
The last video is me riding on the bumper of the Jeep while Keya tried to give me a few mud showers.
This trip was intense, but equally fun. We had to bring our own food, water, and poop bags. We were roughly 40 (very slow very hard) miles from the ranger station and around 100 to the nearest gas station.
I would be happy to answer any questions you have about doing a trip like this (except the location). I also could be convinced to join expedition trips like this. Let me know what you think about the trip or the photos!
Over the holidays, Keya gifted me a nifty little Larson Scanner kit to solder together. It’s a kit that lets you make the cool LED effect from Knight Rider and Battlestar Galactica. Glen Larson produced both which is probably why they have such similar cool effects.
The kid itself is pretty straightforward to put together in just about any order you like. I somehow forgot to solder on the last LED (and I can’t find it anywhere). I guess I’ll have to order a bunch more jumbo LEDs. 🙂
After completing it, I started digging around on the Evil Mad Scientist wiki interested in some of the mods folks have done to it. That’s when I noticed the line explaining how to activate “narrow eye: mode by jumping “opt. 1” on the board. Worked like a charm. I also tested out jumping “opt. 2” on the board and discovered it runs a different linear animation.
Here’s a video of it (should have done it in the dark, but it’s still cool):
What do you think?
Where should I install this thing? Could be a cool addition to a backpack or my drone or something.
It’s been too long since I posted. Much has happened and maybe I’ll get to posting, but for now, here’s 200+ of my favorite photos this year. Let me know what you think!
The travel photos made possible because my employer, Automattic, is fully remote. We’re hiring!
You can also check out my photos from last year.
When I was looking into nifty Raspberry Pi projects, I stumbled across the PirateBox project. The website describes it well:
PirateBox is a DIY anonymous offline file-sharing and communications system built with free software and inexpensive off-the-shelf hardware.
In other words, it’s a bit of preconfigured software you can run on a Raspberry Pi that lets folks chat, share files, and peruse forums on an offline network created by the Pi. Oh, and it’s GPLv3! Open source software FTW!
I have always disliked sharing files via Airplay (Mac-only), Dropbox, or other methods. They work, but require some mental overhead and for everything to magically work. There’s also sharing via USB, but with USB C, that got slightly more annoying.
To me, PirateBox sounded perfect. I could quickly fire up a network from my backpack and share files with those around me. I could use it at meetups or WordPress events after loading it up with some WordPress stuff so folks don’t have to deal with sketchy internet to download software. All pretty pragmatic uses.
I also really like the idea of firing it up when I’m working at busy coffee shops and at conferences to see what folks do with it. Will they try to add malicious software? Will they add poetry and selfies? I guess I will find out!
Yesterday, I downloaded the PirateBox software and loaded it onto a Raspberry Pi Zero W. That’s the itty bitty Raspberry Pi. The folks who put the PirateBox together did an excellent job. It was super straightforward to set up and didn’t require a monitor, or any attached keyboard or mouse. I spotted the PirateBox network on my Mac, joined it, and connected via SSH.
For those of you unfamiliar with SSH, you can crack open Terminal (in Mac) or a console in Linux and talk to another computer. PirateBox walks through the process right on the site.
After I followed the short and sweet setup instructions, I opened a browser window and was greeted with the PirateBox interface.
I tested out just about everything (except the forum) to make sure it worked. Then I decided it was time for me to do some design magic to the interface. It was not the easiest process to figure out as I had to locate the files and understand their build.
How to customize the interface
To customize the PirateBox web interface, you should be comfortable with HTML, CSS, and Javascript. If you’re not familiar, you should either take an online course or pick up a book. It’s super fun!
The important files are all over the place and were somewhat of a mystery to locate. This should help out folks in the future.
The home page
Most of the HTML, CSS, and Javascript files are in /mnt/sdshare/share/content and its subdirectories. They are fairly straightforward. There is some jQuery in use so make sure you keep an eye on which IDs are changed to avoid breaking jQuery functionality. I mostly rewrote the CSS keeping a few of the things from the original. I’ll be open sourcing these shortly (when I figure out the best format).
Localisation
Much to my surprise and delight, there is some basic, but functional localization of the web app. If you want to change text on the home page, you will likely need to change it in multiple places. You will need to change it in the HTML and in the corresponding file in /mnt/sdshare/share/content/locales/. Bonus points if you translate your new or modified strings!
The file browser HTML
I found the file browser HTML to be one of the quirkiest bits. It’s split into three parts. The two you likely will want to mess with are located in /mnt/sdshare/share/Shared/. This is also where your uploads end up by default.
The two files are the first half of the page and last half of the page. The first half is HEADER.txt. Why it is a txt file is beyond me. The second half is in README.txt. Again, why these are this way are a mystery. However, they are just basic HTML and are easy enough to modify.
The chat content
If you for some reason want to clear out the chat or remove a comment, you will need to modify at least one file. The important one is /opt/piratebox/www/cgi-bin/data.pso. If you remove content from this file. the next time someone uses the chatbox, it will regenerate the second file, /opt/piratebox/www/chat_content.html, which is used to render the chat and. This will remove the content. If you want it gone from the chat view immediately, you will need to remove the same content from both.
The results
I wanted to add some breathing room, make it feel friendlier (for my non-pirate friends), and make it look good on high resolution screens so I did just that.
As you can see, it’s not perfect. The header’s a bit big, but hey I did this in an afternoon and I can fix that up as I iterate. I also need to style the upload a bit nicer.
It’s also mobile-friendly and should be fairly accessible. I think a few of the chat box’s form fields could use labels so maybe I’ll add those the next time I mess with it.
The hardware
For those curious, here’s what the final build looks like.
It’s just a Raspberry Pi Zero W with an SD card and power supply. I put it in a nifty case I found on Amazon, but that’s unnecessary. It might even be cool to strip off unused ports to lighten it and put it in a book, wallet, or maybe even a clever laptop case.
Thoughts?
What do you think of this idea? What cool things would you use it for? Leave a comment!
I work for a tech company. I have worked for the government. In both places acronym usage is abundant. In both places, acronyms rarely help achieve clarity. I noticed some acronym patterns and, like everyone else on the planet, I have opinions on how their formatting could be improved.
tl;dr (too long; didn’t read): Acronyms often reduce clarity in communication. Try using fewer acronyms.
I’m writing this on a Raspberry Pi. It has a 2.5 inch screen  and my keyboard is some kind of cheap tiny wireless thing with a track pad that more closely resembles a game controller than a keyboard. Please forgive my brevity or typos. In addition to composing on a small screen, Chromium has a minimum width which makes seeing this editor a bit tricky. Here’s what the whole thing looks like on a 13″ Macbook for scale:
On Saturday Keya and I went for breakfast at a place that happened to be near Microcenter, an electronics retailer. We made the poor life decision to drop in since neither of us had been there in ages. We played with keyboards, security stuff, and IOT things, but what really grabbed their attention was the section with all the Raspberry Pi’s and Arduino projects. Keya got a nifty Raspberry Pi Zero W project and some capacitive thread (for wearable electronics). I walked out with a Pi 3 and a Pi Zero radio project as well as some accessories. We also stocked up on micro SD cards.
The Pirate Radio was the first project I put together. It’s not to difficult and ended up being a delightful airplay speaker when it was all said and done. It is the first “radio” Keya and I have attempted that actually worked (third time is the charm?). It uses a pHAT BEAT addon and a Raspberry Pi Zero W to make the magic happen. I also followed a super simple tutorial to get it done. The only hitch was due to localization settings. Once I switched to the proper keyboard layout and language, everything worked like a charm. Here’s the result:
Once I was feeling confident, I decided to go for putting together the tiny computer with the tiny screen I was imagining. It turned out to be a bit more difficult. The mouse I was trying to use turned out to not work at all. Updating the packages bricked the machine so I had to reflash the operating system a few times.
Learning how to navigate a small screen was an interesting challenge. Pro tip: Use alt + click anywhere on a window to drag it around. This is necessary for windows that have minimum heights and widths. They cannot be scrolled. Once I got the hang of window manipulation, further adjustments were straightforward. I ensmallen the font size and made the menu bar smaller via the appearance settings.
So far I’m loving this thing. What will I use it for? No idea, but it fits rather nicely in any bag and can be powered via my USB batteries. I think my next project might be to make it a local git server or a web server. I also saw something about a VPN or a network ad blocker. Maybe even a robot butler? The cloud is the limit! I ordered a few more thingies to attempt another project or two and if successful, I’ll post the results.
If you have made anything nifty like this or have project ideas, drop them in the comments! If you haven’t and want to, say so in the comments! If you hate these things and don’t understand why anyone bothers with them, let me know in the comments!
Last year Stephane and I took our Jeeps from Montreal to Whistler. This year we met up in Calgary and have about a week to get there. This means we’re taking the scenic route. We also have additional adventurers. Keya and my dog, Zag, are making the trek with us!
Follow our progress here.
This is a copy of a post I initially wrote for a8c design.
The experience of creating a WordPress site can vary wildly. Occasionally, I hear how someone set it up without any major roadblocks. I more often witness nightmare-level setup experiences. Together, with help from the community and hosts, we’re working to improve the process of building a WordPress site.
The fractured flow of the past and present
Putting together a WordPress site is never the same twice. Ultimately, the goal is to create a website with a nifty domain that is available for someone to see. Unfortunately, it is often easier said than done. There are two general paths one could go in to create their WordPress site: the self-hosted route (more control, but more manual setup) and the hosted route (something like WordPress.com where control is limited).
The self-hosted path
The phrase “self-hosted” is admittedly confusing. It doesn’t necessarily mean the user is hosting the site on their own server. It refers to any setup where the user has full control over their site because they either have purchased server space on a host like Dreamhost or, occasionally, they have built and are operating their own server space (super cool to hear when someone does this). Another way to put it is the site’s admin will have FTP access which allows adding, removing, or modifying files on the server and they are also able to install plugins or themes to their heart’s content.
The self-hosted site is like owning a house. You can do what you like with it. You can add a fence or take down a wall. You can paint it whatever color you like. However, when something breaks, you have to figure out how to fix it yourself or pay someone to fix it for you.
The self-hosted path can be somewhat treacherous. I have attended and hosted many WordPress meetups aimed at helping folks out with their WordPress sites. I often meet folks who have encountered unexpected roadblocks when attempting to put together a site as a result of inexperience and complicated flows.
For example, many folks think of websites as a domain. (Those familiar with this process can skip to the next section of this post.) A domain is just an address that points to a server where their site would live, but they don’t know that just yet. So they buy a domain. Then they struggle exploring the settings panels of the site they purchased a domain from trying to figure out just how to get to their site.
Eventually they figure out there’s this other thing they need to pay for called a host. When they find a host, they might notice that hosting usually comes with a domain. All of a sudden the price of their site just went up and they may be feeling a bit irritated at this point because they now just paid extra for a domain without realizing it. Their options are either to get hosting, try to get their money back on their domain, or try to transfer their domain. The latter is probably the most tricky for inexperienced users since anything involving domains is a slow process laden with jargon.
So now they have a host and a domain. With luck, they are connected possibly due to some help from the host’s support team. They are usually pretty friendly and helpful. They see these kinds of requests often.
Now they just need to get their WordPress set up. Again, this can be done multiple ways. With luck, the host will have a one-click install application within the host’s control panel. With even more luck, the user will find it and run it. If they don’t, they may end up attempting the “famous” five minute install. It will not take five minutes. Especially not the first few times they attempt it.
In fact, the “famous” five minute install is mostly famous because it never takes five minutes. It should probably be named, “the famous thirty minutes to an hour install.” This is because it involves steps most folks have never done or even heard of before. How many of you even heard of an FTP client before trying something like this? And setting up a database is… well… it feels like just clicking something might break it since most of the wording is unfamiliar.
There can be any number of complications when doing the five minute install. Some may not even be the user’s fault. I have met folks who tried some fringe host I’ve never heard of or a free host, both of which are incapable of running WordPress, but don’t make it clear to newer users.
Let’s fast-forward a bit assuming they get WordPress installed and running. They have their password. Their domain is hopefully connected. Now they just need to do the thing they were hoping to get to right after they purchased the domain: building a nifty website.
Most folks jump right in to picking a theme. For many reasons, the look of their site is higher priority than creating the content. For those of you who have created many sites, you know that isn’t super necessary. In fact, it likely should be the other way around. So they scroll through infinite themes in the theme directory. They feel that theirs should be unique so they start looking at premium themes. They finally find one they like, pay for it, download it, figure out how to install it… and viola! It ends up looking nothing like the demo site. In fact, it’s nearly impossible from the user’s perspective to make it look like the demo site. How did they get that carousel on the home page? How do I put my articles in those spots? Many struggles, forum posts, and web searches later they have something vaguely resembling the beautiful demo site they thought they could achieve with the theme.
Then they find out they need SEO and a contact form and maybe even a web store. How hard could it be to add those? WordPress has plugins! The first two aren’t too hard. They grab the first SEO plugin they see and a contact form. Both are popular and somewhat straightforward to use. Then they find out creating a storefront is more difficult. Maybe another day…
Now it’s time to create the rest of the content and have a successful site!
That’s the potential route of someone who has a self-hosted site. It doesn’t include things like how the host handles traffic sites (the site might go down), how a plugin update might break things, how certain plugins can slow down the loading of their site, or how to recover a hacked site.
The hosted path
The hosted way is what sites like WordPress.com are where the customization is somewhat limited and the user has no (or limited) access to modify, add, or delete files on the server through an FTP client. Usually they can’t add plugins or themes since those can both include malicious code.
While the self-hosted way is like owning a house, choosing the hosted path is more like getting an apartment. You can customize it a bit, but you can’t just knock down walls where you like. However, it’s unlikely you will do much to break it and, when you do, the landlord has to fix it instead of you.
The experience is a bit nicer in some ways in that it is harder to get lost and folks don’t need to mess with FTP clients or much jargon. On WordPress.com the user can start by picking a theme. Then they can choose the domain they want or add it later followed by a plan. It’s pretty quick from start to site creation.
However, the hosted path can be treacherous as well. In the past, a user might start self-hosted only to realize they need functionality not available within the hosted site’s feature set. They put all this work in to their site and now need to go the self-hosted route, which used to be a bit of a bummer because it involved exporting content and trying to recreate functionality along with the joys of setting up a self-hosted site.
But, hey. We’re working to make it much better and we’ve already got flows in place that dramatically improve the experience through WordPress.com.
A unified WordPress experience
At Automattic, we have been working for the past few years from different angles to help unify and improve the WordPress experience as whole benefitting the community, the hosts, the developers, and, most of all, WordPress users.
Working with hosts
We are continually working with and reaching out to hosts to do what we can to make the WordPress experience better. This includes encouraging simpler setup flows bringing one click installs into the process rather than at the tail end. It also includes getting Jetpack and Akismet preinstalled and set up without the user having to do too much or pay extra. Dreamhost does a pretty good job of this. We also work with the community to encourage hosts to upgrade to newer versions of PHP so users aren’t stuck with older versions we no longer support.
The future of moving a site
Right now, if a user starts on WordPress.com and the needs of their site grow beyond what is available on our platform, we offer multiple ways for them to move to or from a self-hosted setup.
The first path to move to a self-hosted setup is similar to what I previously mentioned in that we let the user export data as usual. They can then import everything on their self-hosted site.We also allow the download of many themes so there’s a good chance they can use the same theme. As a bonus, we also encourage installing Jetpack which gives them back all of the features they had on WordPress.com. This means if they had custom post types set up, they will just work correctly after activating Jetpack.
The second path is a pretty hands-off version of the first. It’s called Guided Transfer and includes the migration of a WordPress.com site to one of our recommend hosts. It includes migration of all the content, stats, themes (sadly not premium themes), and setting up Jetpack on the host so the user still has all of the features they are used to. They can even continue to use WordPress.com’s interface to create or add content if they like. It’s fairly seamless, but can be slightly rough if their theme can’t be transferred.
Now, it is also possible to move a site from a self-hosted site to WordPress.com. It’s fairly manual and involves exporting data from your self-hosted site and importing it into the WordPress.com website. If the user had Jetpack installed, all of the features they used there will be available on WordPress.com as well. We can also move over followers and stats upon request.
Basically, we have created a product that allows a user to move the content to a place that gives them the tools they need to grow their site. It’s a two-way stream and helps our hosting partners, our users, and hopefully lightens the workload on developers tasked with migrating sites.
The future path is something even simpler and friendlier. It would involve an interface allowing seamless transfer from one place to another with the option to select a host or something like WordPress.com. Let’s see if we can come up with something.
The Jetpack
Another major move to unify the WordPress experience has been through Jetpack. We have built a product that provides a bridge between the WordPress.com platform and self-hosted sites. The latest iterations involve an interface that matches up with WordPress.com’s and even encourages using WordPress.com to manage or create content. It also includes the ability to sign in to your self-hosted site with your WordPress.com login. Â These features are pretty handy for those of you with multiple sites and even if you don’t, there are several pretty useful ones for any site.
Several of the features provided benefit developers, hosts, and the users. For example, there is a feature that serves your images from our servers (Photon). This lightens the load on hosts. It also serves the images at the proper size for the device it is loading on. This means it loads them extra crispy and detailed on devices with high resolutions. This makes the users happy since their photos will always look super sharp.
Behind the scenes, there are all sorts of developer-y things baked into Jetpack that a developer can hook into to make the site hum exactly the way they want. For example, Photon has an API that lets them apply Instagram-like filters if they want. They could make all the images on the front page black and white or with a color tweak.
The ideal
Ideally, we want to build a system that doesn’t particularly care where the user starts or ends up as long as it gets the job done well. We want them to be able to create a site that has everything they need without going through too much trouble. If they need to move it, that’s fine.
We want to build paths to WordPress that benefit our hosts. Making the setup flows easier and the maintenance painless is super important. If we cut down the setup time dramatically, more people will successfully build sites and stay on their host.
And we want to benefit our WordPress experts and developers. You folks are the backbone of this ecosystem. We are working to provide pretty nifty tools and toys you need to do your work well. We’re going to continue to providewhat we can to help you build really nifty sites. The less time you have to spend struggling through site migrations or restoring broken sites, the more time you can spend on the fun stuff.
The Next Levelâ„¢ ideal
Even more ideally, we will build a system that works so well one could build their entire site right from our mobile apps without having to jump through too many hoops to get it set up.
And even more Next Levelâ„¢… VR setup flows! How dang cool would that be? Rami Abraham made a pretty cool video of what that could be like somewhere on the internet. @ him for more info on it.
What do you think?
Got any ideas you’d like to try or see us try? Let’s continue to work together to make building the web pleasant and maybe even pretty fun (dream big, right?).
During our stop in Ojo Caliente, we headed up the road behind the hot springs and found some nice gnarly roads to bike on with Zag. We ended up by a neat mica mine. I had never seen mica grow that thick before. Zag also got a couple minor lessons about what cactus are and what he shouldn’t scratch his back with (he’s okay).
Santa Fe
In Santa Fe, I did a quick route up the Dale Ball loop to see if it would be something we would want to do the next day. It was a bit too gnarly so we moved on.
Albuquerque
Keya had the bright idea to head down to the river and do a bit of longboarding on the path in the evening light.
We then hit up the Elena Gallegos central loop the next morning. There were plenty of “cactus consequences” along this trail.
Photos by Keya and myself.
