In a previous post, I talked about using Docker as a way to stub out calling to external APIs. I showed how I could use my Ruby-based Sinatra-Mock framework to stub out APIs that are port-based. One of the limitations of my framework is that I can only mount to open ports, so I was limited to stubbing port-based APIs.
Since that post, I needed to mock out an API call that was tied to a port 80 HTTP-based API.
There are several open-source and free solutions that provide Elasticsearch access authentication, but if you want something quick and simple, here is how to do it yourself with just Nginx…
I’ve been using an ELK stack to store my logs. I was using a random port, so I was only protected by the good, old security through obscurity method. This made me uncomfortable since anyone could read or post to my logs, but I didn’t want to use X-Pack or SearchGuard because they both felt too heavy for my simple use case.
At my day job I work on a lot of APIs. I build APIs, I talk to APIs. It’s API city for me.
Most of the time, I’ll communicate with a development API as part of my testing. This works great in most cases, but occassionally I want to have the API I’m interacting with return specific responses and HTTP status codes. This can be tedious/impossible when working with a real API, even in a development environment.
It’s a requirement that anyone who moves a blog from Jekyll to Hugo write a post about their migration. I’ll do the same and will also talk about Victor, the Hugo equivalent of Lanyon.
Why I was pretty excited about Jekyll (as I mentioned in my previous post); however, I quickly came across a common problem: it is slow to build. I read some accounts where it could take minutes, as your site grew and you added things like tags and categories.
I finally made the move to migrate this site away from Tumblr. I originally used Tumblr because it was a simple alternative to the heavier blogging sites/frameworks like Blogspot and Wordpress. I tend to enjoy simplicity when it comes to my personal projects, leaning on Sinatra for Ruby-based projects and Silex or Slim for PHP projects.
While I was researching alternative blogging platforms, I found Jekyll. It’s a different type of blogging platform, where you build your posts as individual HTML/Markdown files and use the Ruby-based application to build static files that can then be hosted on a variety of platforms.
While I’ve built several deployment projects in the past (Fabox, Giply, Ripple), I’ve given it all up because of a little project called Docker that has taken the world by storm.
Dokku It started with a project called Dokku. Dokku was similar to where I envisioned Ripple moving to as I started investigating integration with Docker (it used bash instead of Ruby for automating tasks). At the time, it relied heavily on Heroku buildpacks (the project now supports Dockerfiles).
Looks like the next iteration of OS/X will still again not ship with a recent PHP version.
We are happy to confirm that Android Studio, the new IDE for Android development that Google is developing in cooperation with JetBrains, is based on the IntelliJ Platform and the existing functionality of IntelliJ IDEA Community Edition.
JetBrains is one of the best developer tools companies out there IMO. I have happily paid for PHPStorm and RubyMine out of my own pocket as the apps are just worth it.
The problem comes from the fact that the new Ruby 1.9 installation doesn’t find the certification authority certificates (CA Certs) used to verify the authenticity of secured web servers.
If using Homebrew:
brew install curl-ca-bundle
TL;DR: PHP is still a poor choice for continually-running processes. See this post for context. Read on for more proof.
There’s been some reaction to the previous entry. Some people agreed, mostly seasoned PHP folks, some others just didn’t. Yeah, apparently it pleased or infuriated more than two folks in the entire Internet.
First and foremost, a correction to previous statements: PHP’s 5.3+ enables garbage collection by default, it’s an opt-out feature, not opt-in.