A couple of months back, I started playing with Laravel. So far, it’s been fun; at the very least, it’s nice using something more modern and popular than Yii 1. However, Laravel’s also more modern in their asset management system, and I still possess curmudgeonly feelings about this whole JS-ifying of all of our tools. I had to figure out how to use Gulp. Gulp

In previous projects, I used Compass to handle my Sass. I’d also go grab the Sass-globbing plugin, which had incredibly simple instructions for inclusion in Compass. My attempts to do similar with Sass and Elixir… hit some road blocks.

A note about globbing: I do not understand why anybody is okay with explicitly including every single Sass partial. It’s an extra step, and extra cleanup, and does not encourage breaking ones Sass out into clean components. Globbing allows you to include entire directories of partials rather than explicitly including individual files. That means no adding to the long list of partials in your main file when you create a component, and no cursing when your Sass fails to compile because you removed the partial of a component you no longer want. This is today. We have the technology.

Anyway, while I was trying to figure out how to get Sass globbing happening without Compass, I found out Laravel supports a preprocessor I’d never heard about: Stylus.

Stylus comes with globbing by default.

So I got Laravel hooked up with Stylus and, so far, I’ve really been enjoying it. There’s minimal syntax junk, and a few interesting extra features. To me, it doesn’t just feel like CSS+, but like an elegant programming language of its own. Just check out how gorgeous their “transparent” mixins are. And variable declaration uses an equal sign instead of looking like you’re defining a property, a distinction I personally appreciate:

Stylus Variables in Action

I’ve since learned that there does seem to be a package for using Sass globbing with Grunt. I haven’t tried getting it set up, because right now, I’m not ready to go back to Sass.

It was 3:23PM.

I was reading a tutorial about something unrelated when I was told that setting up a free SSL cert and HTTPS with NGINX is easy. That there’s something nifty now called Lets Encrypt, and that they just give out free certs like candy, and make it easy to config too.

I remember being told that that was a daunting task years ago. I don’t know all that much about HTTPS, but I’ve been on a little bit of an encryption kick lately. There was no way I was going to pass up the chance to add a little extra security to the internet!

So I go to letsencrypt.org/getting-started/

I’m told I should use certbot, since I have shell access to my server.

At certbot.eff.org/ I tell a cute robot-key-creature what web server and operating system I’m using — NGINX and CentOS7. The cute robot tells me to add a repository I already added years ago to my yum repo list, so I skip that step and simply run sudo yum install certbot-nginx. It works.

The site tells me I can go all-in via sudo certbot --nginx, in which case the package will go ahead and edit my NGINX conf files itself, or I can just use the certbot to get the cert and set up the confs myself. I went all in.

I was given a few basic prompts — I was asked for my email and had to agree to ToS — and then it got cool. It asked me which hosts I wanted to set up. I didn’t have to do anything and there was a list of what I believe are all the domains pointing to my IP, including with “subdomain” specificity. I chose to only set up www.willowsells.com and willowsells.com…

And then it failed validation.

The error message:

Failed authorization procedure. www.willowsells.com (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Error getting validation data, willowsells.com (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Error getting validation data

My firewall wouldn’t let the certbot reach out and do what it needed to do. Being impatient, I temporarily turned off my firewall rather than configuring it to allow HTTPS and then I re-ran the certbot. I got another prompt asking me whether or not I wanted to force the site(s) to direct to HTTPS and that was that. There was my site, running HTTPS, and doing a 301 redirect for the HTTP URLS!

I did have to enable HTTPS on my firewall and restart it. Running sudo firewall-cmd --permanent --add-service=https and sudo service firewalld restart did it!

My site was running HTTPS and only HTTPS by 4pm. It was glorious.

Which isn’t to say there weren’t other problems. My site wasn’t actually running properly.

Yes, certbot inserted the rather simple nginx confs in the right spot to get my site to serve HTTPS and redirect HTTP. This is surprising, really, as I have a rather odd nginx setup; I use nginx both as my server and my cache server, with one server block listening on port 80 and cacheing things and an upstream server block listening on and serving files or whatever PHP gives it. Based on the console output from certbot, it did experience some confusion with my conf files, but it nonetheless accurately put this in the right server block (the top-level one):

listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/willowsells.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/willowsells.com/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot

if ($scheme != "https") {
return 301 https://$host$request_uri;
} # managed by Certbot

# Redirect non-https traffic to https
# if ($scheme != "https") {
# return 301 https://$host$request_uri;
# } # managed by Certbot

But when that first server block handed off the request to the second server block, it didn’t hand off the information explaining that the original request was HTTPS, and the PHP generating my site at the end certainly had no knowledge of whether or not the site was HTTPS. As I understand it, this is a potential problem with HTTPS and proxies for frameworks other than WordPress, but it is definitely a problem for WordPress.

Completely expectedly, I had to go through the usual process of changing WP over to using the new URL with the https in it instead of HTTP, but that’s just a given part of the process of working with WordPress. Once I did that, the site was mostly working — except for the dashboard. If you try hitting the HTTPS version of the admin section of a WordPress site, WordPress wants $_SERVER[‘HTTPS’] to be set. It has to be set, I believe, to either 1 or ‘ON’. Otherwise you’ll get an endless redirect loop.

There are a number of unpleasant ways to get around this, and I’m not certain this is the one I’m going to go with in the long-term. Maybe I’ll just finally give in and stop using WP. But in the meantime, I simply added this in with the other stuff in my nginx config directing extra variables to be handed off to fast_cgi by NGINX: fastcgi_param HTTPS ON; and voila, no more redirects!

Thankfully, in writing this, I went back to look at the certbot website, and realized there’s an additional step I have to do, some time in the next 90 days. Apparently LetsEncrypt certs expire every 90 days, and while it’s at least as straightforward to renew them, one still has to do so. The certbot recommends setting up a process that tries to renew them twice a day every day. Better safe than sorry and all that.

Hopefully I’ll remember to do that tomorrow.

When someone posts on Facebook that they’re throwing out a 3D printer, you convince them to give it to you, period. You don’t ask silly questions like why they’re throwing out the printer, or what model it is, or whether or not it even turns on. After all, even in the worst case scenario, there are going to at least be parts to scavenge!

This was how I ended up with a Tiko as my first (and currently only) 3D printer.

If you’ve never heard of the Tiko, it was a Kickstarter project that failed. Miserably. So miserably that it’s exceptionally difficult to get useful advice on the printer; people just want to talk about how awful the Tiko is.

The printer does, in fact, work. It turns on. It broadcasts a wifi network. Its web interface “works,” though just opening the page turns the console very red. At some point I had to manually set a variable in the console in order to get it to connect to my wireless network, and there were further problems that cropped up when it tried to update the firmware.

It prints things. My first print was, in fact, better than many other first prints people got on the Tiko, it seems. It at least stuck to the bed all on its own.


See all that damage to the print bed? I received the printer that way, but as I understand it, that’s a common problem people have been having using the “auto-calibration” option with the Tiko.

The thing is, auto-calibration is more important for this printer than others. Tiko took being “The Unibody 3D Printer” too far. Sure, it’s cute (though I think the most aesthetically pleasing features have nothing to do with it being unibody). But it’s pretty standard to manually calibrate a 3D printer using a piece of paper between the nozzle and the bed… which you can’t really do with this printer. When assembled, you have no access to the print bed.

So… we fixed it.

I also heard (and saw gorgeous photos of!) great reports coming from some people who had started using the Cura slicer instead of Tiko’s built-in nonsense. I wish I could say that fixing the calibration issue and giving it better GCode allowed me to suddenly be able to make great prints. But this has not been the case.

The Tiko seems to occasionally throw fits half-way up the Benchy model I’ve been using. I know other Tiko users have had similar problems as my blue half-benchy below.

Frustratingly, this has never happened while I was watching it. The conclusion I’ve reached is that clearly my Tiko just doesn’t like it when I’m gone for too long. It did the below with some ABS when I stepped away for a quick shower.

Yes, I did just say ABS. I know the Tiko generally isn’t considered ABS-friendly; after all, the print bed isn’t heated, something often considered required for printing with ABS. Hower, the best print I got pre-Cura was with ABS. Below is the third thing I tried to print on my Tiko, before the modification to its body and before switching to using Cura.

That may or may not have been my best print, period. I then tried to do the same thing with the Tiko’s Gem PLA, with a slight temperature decrease, and got this nonsense.

I eventually managed to get this guy with the Cura slicer and some ABS on a very stickified bed (absolutely necessary with this bed).
Tiko-with-First Semi-Successful-Benchy-ABS

Really, if it wasn’t for the results with ABS, I probably would have given up on the Tiko all together. Which would have been quite sad, considering how much fun I’ve had learning slicer settings! After trying some ABS out in the Tiko, I was quite convinced that the PLA was simply bad (which I’m still not certain it isn’t, to some extent)… but then my friend used it in a MakerBot to create the handsome print below.

My suspicion, especially after more prints and having opened up the extruder on this thing, is that the extruder can’t really handle the thinner Gem PLA. The teeth slipping on the filament could easily explain what seems like unevenness in the PLA extrusion — something my extensive playing around with temperature settings has not yet fixed. Sadly, there does not seem to be an “easy” way to get the single bearing to push the filament any closer to the only gear’s teeth, to compensate for deviation in filament diameter. I did recently widen the last segment of the filament path in the extruder, as I noticed the tight-looping Gem PLA would occasionally get caught on an edge and it made feeding in filament occasionally very annoying.

Thankfully, not all of my Tiko problems seem to emanate from the extruder! I’ve realized that the print bed for the Tiko is awful. I can excuse it not being heated, and I know having to use tapes and glues and the like is perfectly normal with 3D printing. But all of that aside, the bed is quite simply uneven. So post #2 on my Tiko experience will hopefully include updates on attempts with a custom glass print bed! Worst case scenario, I should at least be able to print some useable gears with the Tiko, some ABS, and a heated glass print bed — more than I could really have hoped for from a free, second-hand, bankrupt 3D printer!