| jdjkelly> uh | |
| jdjkelly> did anyone bring the buttfor? | |
| mnote> *what's a buttfor*? | |
| mnote> :) | |
| jdjkelly> for pooping, silly |
Elixir is a beautiful language. Among its strength is its powerful pattern matching system which allows one to write very declarative, elegant code. FizzBuzz is a trivial problem often presented to new programmers or interviewees to determine baseline programming ability. Here is a solution Elixir:
defmodule FizzBuzz do
In an experiment to try to squeeze as many unicorns as I could out of a single dyno on Heroku, I built a version of this website on top of Roda, a thin routing layer for Rack.
It was successful experiment, between freezing about every object I could find, and a lot of other various tweaking, I had an app that provided me the convenicence of the workflow/tools I'm used to (code-reloading, Sprockets,
I ran into an issue getting a simple Capybara/Poltergeist feature test suite running against a site that used React.js. The following failure was bubbling up to RSpec.
Failures:
My first exposure to Lua was in highschool. When I started seriously programming in tenth grade, it was in C (though I'd had some exposure to C++ as early as elementary school.) Being a nerdy teenager, all I wanted to do was make games, and I quickly discovered that doing everything in pure C had some downsides, and that embedding a scripting language within your application was commonplace for reasons that I have no intention of explaining here. I assume you already want to embed Lua in your C application, else why would you be reading this.
I've never worked for a product company, and I have lots of personal projects. Because of this, I find myself jumping between different projects constantly. I manage this by keeping up to date Teamocil profiles for each project I work on, and using a development tools that fit completely inside of a tmux session (with the exception of my web browser, of course.)
There are lots of kinds of projects where your tools can't all run inside of
I don't like Sprockets, but it's the easiest and best choice for lots of Ruby on Rails projects. When looking for a better way to manage my JavaScript assets and an improved developer story, my current tool of choice is webpack. While I wish Rails supported drop-in asset pipelines the way that Phoenix does, it's not hard to use webpack with Rails.
Note: This article is more generally about how to add dependencies to a Rake task, and why you might want to do that.
If you followed my previous article on webpack and Rails, you might have built yourself a trendy little React app. Then you tried to deploy it, and that didn't work, did it?
In part 2 we set up a Rake task to run webpack, ensuring that most deploy systems would build our entries for us.
I missed that we needed the webpack Rake task to be run before feature tests too. Without this, we need to run the task manually before running our test suite to avoid erroneous failures due to the assets not being up to date. Running Rake tasks from anywhere in your application in relatively easy, but we
I hereby claim:
To claim this, I am signing this object: