Worked 2015-09-08 for Phoenix 1.0.1 on Dokku 0.3.25.
These instructions assume you've set up Dokku. If not, go find a tutorial for that part. My notes for setting it up on Digital Ocean.
Create a Dokku app:
# You will need fswatch installed (available in homebrew and friends) | |
# The command below will run tests and wait until fswatch writes something. | |
# The --stale flag will only run stale entries, it requires Elixir v1.3. | |
fswatch lib/ test/ | mix test --stale --listen-on-stdin |
# For simpler use cases, see the UsesTracker instead: | |
# https://gist.github.com/christhekeele/e858881d0ca2053295c6e10d8692e6ea | |
### | |
# A way to know, at runtime, what modules a module has used at compile time. | |
# In this case, you include `IndirectUsesTracker` into a module. When that module gets | |
# used in some other module, it makes that module registerable under a namespace of your choosing. | |
# When the registerable module is used into a third module, that third module will know at runtime which | |
# registerables were `use`d in it at compile time, via a function titled after the namespace. |
# For more elaborate use cases, see the IndirectUsesTracker instead: | |
# https://gist.github.com/christhekeele/fc4e058ee7d117016b9b041b83c6546a | |
### | |
# A way to know, at runtime, what modules a module has used at compile time. | |
# In this case, you include `UsesTracker` into a module. When that module gets | |
# used in some other module, it registers itself with the other module. | |
## | |
defmodule UsesTracker do | |
Worked 2015-09-08 for Phoenix 1.0.1 on Dokku 0.3.25.
These instructions assume you've set up Dokku. If not, go find a tutorial for that part. My notes for setting it up on Digital Ocean.
Create a Dokku app:
Flask-SQLAlchemy has some nice built-ins (e.g. accessing query
directly on classes). To continue leveraging these nicities while still inside of a Celery worker, we need to make sure we setup/teardown in a similar fashion to Flask-SQLAlchemy does on Flask.
Flask-SQLAlchemy uses create_scoped_session
at startup which avoids any setup on a per-request basis.
https://github.com/mitsuhiko/flask-sqlalchemy/blob/2.0/flask_sqlalchemy/__init__.py#L668
This means Celery can piggyback off of this initialization.
defmodule Curried do | |
defmacro defc({name, _, args}, [do: body]) do | |
curried_args = Enum.map(Enum.with_index(args), fn({_, index}) -> | |
Enum.take(args, index + 1) | |
end) | |
for a <- curried_args do | |
if a == Enum.at(curried_args, Enum.count(curried_args) - 1) do | |
quote do | |
def unquote(name)(unquote_splicing(a)) do | |
unquote(body) |
source 'https://rubygems.org' | |
gem 'rake' | |
gem 'lotus-router' | |
gem 'lotus-controller' | |
gem 'lotus-view' | |
group :test do | |
gem 'rspec' | |
gem 'capybara' |
I want to write plugins for Atom's editor in Ruby. Opal makes this possible. Atom is one of several projects in recent times to combine Chromium with Node.js for a desktop app. While it utilizes chromium for it's gui, and boasts "[e]very Atom window is essentially a locally-rendered web page", writing Atom plugins is more like writing a server-side node.js app than a typical single-page client-side app (albeit with really awesome integration with Chrome Devtools). Opal development, on the other hand, has to-date been focused primarily on the browser use-case.
Because of this, I had to make a choice between using the opal-node package from npm, using Opal via Ruby w/ a compile step, or packaging up opal-parser.js, including it with the app, and writing in compilation on the fly. Each choice came with compromises. Using opal-node would have been easiest, just create a top level index.coffee that required opal-node, and then require in your ruby
These are my personally cultivated styleguides for different types of text (normally code or markup).
They're less about common conventions (ie. put single spaces between sentences or new lines between different contexts) and more about what syntax features to prefer or avoid in which contexts. As such, they expect the reader to be familiar with the language or markup in question. They are not suitable introductory material to a syntax.
Comments and discussion are welcome, otherwise I'd just keep these in my head instead of on a publicly available forum. I especially invite you to try and change my mind: these, like all opinions and code, are works in progress; not absolutes.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in the OXFORD ENGLISH DICTIONARY.
A micro-gem DSL for compound conditionals.
Allowable lets you decompose large/long conditional chains into readable, testable, and inspectable segments with Ruby blocks.