Karl Oscar Weber March 07, 2023

So you want Ruby to grow?

A very flat looking pinkish Ruby shape thing, with a few other rubies fanning out beneath.

So you like Ruby, and the Ruby community, and you want it to grow? What should you do?

1. Write stuff for beginners.

Always, and first, and primarily, and when you think you've done enough, write more for beginners. I cannot tell you how important it is to write for beginners. The stagnation of new Ruby developers, junior developers, can be attributed to a lot of factors, but the primary factor is that the moment a beginner makes it out of the getting-started page, everything else is for Computer Science Majors/Ruby lovers/Expert Developers. Basic concepts are ASSUMED, which I guess makes sense, but also mildly complex concepts are also ASSUMED. All of this assumption means that practically any tool that Rubyists write for one another is not user friendly.

"But I understand this KOW! This stuff is easy for me."

Right Right Right, but you're not a beginner. If you've been in the Ruby game for about 2 years things start to make a lot more sense. But if you haven't been doing it for that long it's just still a little magical and hand wavey. A lot of Ruby's utility comes from it's metaprogramming abilities, but those take some time to truly grasp.

So please, write stuff for beginners, write more than just "Documentation". Write Getting-started guides, How-to guides, Common use cases documentation, plus examples in standard ruby and with at least 2 frameworks. Bonus points if neither are Rails.

Also please review some basic Ruby stuff when talking about your framework. Dig in a little. Don't assume that we know how this works. We don't. Make it easy to be successful with your code.

2. Focus on Diversity, Equity, and Inclusion.

I know that some folx don't think it's important. Those folx are wrong. and Stupid. Expanding Ruby means finding people that are overlooked, under-appreciated, and then supporting them. I don't know if ya'll have noticed but almost all tech people are hella white. Just whitey tighties all up in here. Me too. Male, White, Heterosexual, Cis-Gendered, Heck I'm even Christian. I know across the pond and out East it looks a lot different.

Growing Ruby requires building strong community outreach, training, retention, and promotion of folx that don't look like, think like, or talk like the majority of Ruby developers today. I'm serious. If you look around at the current "tech" landscape today. What people are using to make their websites and apps. You won't notice that folx are making these decions based purely on the merits of a technology. It's based on Culture and perception. A whiteness centered culture has driven folx to widely adopt some bad tech. This is a direct result of prioritizing the needs of young, childless, single, white men. People who can work for hours or days on a problem because they hav nothing else to do.

Getting more folx to use Ruby, means going against the grain of tech culture itself.

Give these folx raises, a seat at the table, Hell a piece of the table. Bringing people in to Ruby that aren't already there means accomodating them. Increasing the realm of what's possible. What does that mean? fewer hours? more flexible work schedules? More mentorship? It means doing whatever it takes to bring these folks into the community. Including financial help. Drop a couple of Ks a year, at least, to sponsor, promote, or support under-represented folks coming into the Ruby community.

Forge strong connections with beginners, help them to build their professional networks. We're not getting hired based on our resumes, that almost never really happens. And if that's not the case then we ought to be helping, maybe even focusing on building these relationships with newcomers.

Also NEVER dictate what a donation or support should be used for. People know what to use their money on. Once you give them money, it's theirs.

There is this really silly... assumption? phrase? The best person for the job. The best person for the job doesn't exist, also who cares. We need to find people who are motivated, and kind. Folx that want to grow and improve. The junior developers of today, are the staff engineers of tomorrow. A beginners perspective sheds light on the spaces infrequently seen by an expert. The entrance.

Don't take my word for it. Read Kim Crayton.

3. Promote Framework diversity.

I am biased because I've been performing Necromancy on Camping for over a year. But sincerely, do your best, BEST, to promote framework diversity. A mono culture breeds in weakness. Everyone using Rails when they use Ruby means that only a certain narrow band of problems are easily addressed. It means that different perspectives or priorities are ignored.

Like Motoko Kutsanagi says: "If we all reacted the same way, we'd be predictable, and there's always more than one way to view a situation...It's simple: overspecialize, and you breed in weakness. It's slow death."

So too goes the Ruby way. Overspecialized in a single monolithic framework, All Roads, well rails, lead to… well rails.

Some Great alternative frameworks and tools:

Hanami
Sinatra
Bridgetown
Roda
Camping (Maybe it'll be ready by the summer)

The monoculture is really bad, but there are great signs of this changing. The rise of Hanami and Roda as framework alternatives. The steady march of progress with RACK and it's associated projects. Sinatra just got a brand new release. Phlex, a new templating and component library, seemingly brought to life from nothing in about six months by Joel Drapper, and it's fast as hell. The joy around writing with ruby hasn't abated, and genuinely feels like it's accelerating.

4. Teach more than just Ruby!

This is a big one! Most of what we're doing is making websites. There is no ruby on a webpage. I bet you didn't know that it was just a bunch of HTML,CSS, and Javascript. But it is. Like for reals.

Recently I had the necessity to make a mostly static website, I tried out Bridgetown for the first time, and it was great. Almost no hickups, and I used just regular old HTML, CSS, and JavaScript. Almost no JavaScript also. Kids these days think that you need complicated build processes to get a site online. Every "Hello World" or "Crud App" looks so bad because they are devoid of styles. Exceptions to this are few.

If you want to get folks to adopt Ruby, make it easy for them to understand the problem they have, and to find the solutions to the problem they have. Teach the whole enchilada. Top to bottom. Give examples and use cases. I know ya'll know how to do this stuff.

Teach around the problem. Keep folx in your documentation and solve as much of the problem as you can. Hell it will be reference for yourself in a few weeks when you forget something basic anyways.

5. Excise harmful folx

Kick em out. Are they being Racist DumbHasHasses? Show them the door. Are they taking credit for other folx work? Get outta here. Genius is a myth, aint nobody got it.

Harmful, bigotted, and prejudiced folx drive away the exact people you want to bring into the community. They gatekeep and centralize power and influence. Centralized systems have a single point of failure. When it comes to people, it makes a community brittle, poised to either break and fracture, or pull the whole lot down a darker path. Harmful folx narrow perspective, and thus, awareness of what's possible or important.

This may not be a completely bad thing though. The majority of the reason I'm working on Camping, and focusing on this community, is sheer rage at the idiocy of some folks here. A combination of Rage and Sunk Cost Fallacy.

My dad always said that sometimes anger can be a great motivator. Something won't get fixed until you get angry enough to go fix it yourself. That's why I'm here folks. I'm hella Angry.

Karl Oscar Weber February 21, 2023

Isolated

I feel socially isolated by the structure of the place I live in. I like Art, Design, and Culture. Outside of the black mirrors I have, I don't see it, hear it, or experience it.

The physical structure of Western America is shit. Everything requires a car. A car to here, a car to there. The cars are expensive, and dirty, and fucking suck. We live in houses, single family homes. With a nice big buffer between each house. I never see my neighbors except when i glimpse them moving to or from their cars and their homes.

Society is designed to keep us poor, tired, stupid, isolated. To wring out the creativity from our souls, to leave us empty and dross. It is designed to be this way.

We can design something better, but it will take intention. We can improve our lives, and the lives of our neighbhors, but it will require a fuck ton of work. I wnat to do that work but I'm not sure how to start. Maybe I'll write my name on every wall I find. See if that helps.

Karl Oscar Weber February 09, 2023

Fluid Type Scales with Utopia

Responsive websites are really cool. Most websites are responsive now. It's just how we do things. But how we get to a responsive website isn't always so easy. We end up with results that are... inconsistent to say the least.

A few years ago some interesting fellows proposed a completely fluid type scale to help us adapt our letters to smaller and larger screen sizes. They called it Utopia.

The problem™ is that good typography has a sort of hierarchy, and a relationship to that hierarchy. Headings are LARGE, and subheadings are not so large, text is normal sized. On large screens the gap between these sizes are bigger than they ought to be on smaller webpages. Traditionally these changes are achieved through media queries:

h1 {
    font-size: 1.5rem;
    line-height: 1.1; 
    @media (min-width: 375px)  { font-size: 2rem; }
    @media (min-width: 640px)  { font-size: 2.5rem; }
    @media (min-width: 960px)  { font-size: 3rem; }
}
h2 {
    font-size: 1.25rem;
    line-height: 1.2;
    @media (min-width: 375px)  { font-size: 1.5rem; }
    @media (min-width: 640px)  { font-size: 1.75rem; }
    @media (min-width: 960px)  { font-size: 2rem; }
}
p {
    font-size: 0.875rem;
    line-height: 1.5;
    @media (min-width: 375px)  { font-size: 1rem; }
    @media (min-width: 640px)  { font-size: 1.125rem; }
    @media (min-width: 960px)  { font-size: 1.25rem; }
}

This is a contrived example, but shows that the ideal size for our text is different across screen sizes:

Font Type Scale showing type scaling from small to large.

Clever folks have found out that setting your type at different sizes is more pleasing if there is a consistent ratio between those sizes. Let's say, like a third smaller, or a third larger at each step. It might look something like this:

5 rows, each has a type size, a circle that matches the size, and some sample text that is the text size of that row. The circle size and sample text descend in size by a third in each row. Thsi shows visual hierarchy in type sizes.

We call this phenomenon a Type Scale.

Fluid type scales respond to the viewport size. Smaller screens have less space, the gap between sizes on the scale should be smaller than on our big screens. A smaller, mobile type scale might look like this:

A Mobile type scale consisting of 5 rows. Each row has a pixel size label, a circle that matches the pixel size, and some text that matches the pixel size. The rows are smaller as they descend.

As you can see the type scale looks different. It's smaller, and the change in sizing is smaller too. The type scale begins at 16px and increases by 20% at each scale. A less dramatic change than beginning at 20px and increasing by 33.3% each scale.

Executing A Fluid Type Scale in CSS

Thanks to CSS Variables we can execute fluid type scales:

/* @link https://utopia.fyi/type/calculator?c=320,16,1.2,1280,20,1.333,4,0,&s=0.75|0.5|0.25,1.5|2|3|4|6,s-l&g=s,l,xl,12 */

:root {
  --fluid-min-width: 320;
  --fluid-max-width: 1280;

  --fluid-screen: 100vw;
  --fluid-bp: calc(
    (var(--fluid-screen) - var(--fluid-min-width) / 16 * 1rem) /
      (var(--fluid-max-width) - var(--fluid-min-width))
  );
}

@media screen and (min-width: 1280px) {
  :root {
    --fluid-screen: calc(var(--fluid-max-width) * 1px);
  }
}

:root {
  --f-0-min: 16.00;
  --f-0-max: 20.00;
  --step-0: calc(
    ((var(--f-0-min) / 16) * 1rem) + (var(--f-0-max) - var(--f-0-min)) *
      var(--fluid-bp)
  );

  --f-1-min: 19.20;
  --f-1-max: 26.66;
  --step-1: calc(
    ((var(--f-1-min) / 16) * 1rem) + (var(--f-1-max) - var(--f-1-min)) *
      var(--fluid-bp)
  );

  --f-2-min: 23.04;
  --f-2-max: 35.54;
  --step-2: calc(
    ((var(--f-2-min) / 16) * 1rem) + (var(--f-2-max) - var(--f-2-min)) *
      var(--fluid-bp)
  );

  --f-3-min: 27.65;
  --f-3-max: 47.37;
  --step-3: calc(
    ((var(--f-3-min) / 16) * 1rem) + (var(--f-3-max) - var(--f-3-min)) *
      var(--fluid-bp)
  );

  --f-4-min: 33.18;
  --f-4-max: 63.15;
  --step-4: calc(
    ((var(--f-4-min) / 16) * 1rem) + (var(--f-4-max) - var(--f-4-min)) *
      var(--fluid-bp)
  );
}

Notice in the code above that we have the --fluid-min-width and --fluid-max-width set to 320 and 1280 respectively. These are our limits. Our fluid sizes will reach their smallest at the lowest limit, and their largest at the biggest limit. This also prevents our text from shrinking or growing without end. (The math is difficult to parse without a minor lesson in algebra, so let's not do that.)

You can achieve the same effect, although with a bit less precision, and precalculated, with clamp:

/* @link https://utopia.fyi/type/calculator?c=320,16,1.2,1280,20,1.333,4,0,&s=0.75|0.5|0.25,1.5|2|3|4|6,s-l&g=s,l,xl,12 */

:root {
  --step-0: clamp(1.00rem, calc(0.92rem + 0.42vw), 1.25rem);
  --step-1: clamp(1.20rem, calc(1.04rem + 0.78vw), 1.67rem);
  --step-2: clamp(1.44rem, calc(1.18rem + 1.30vw), 2.22rem);
  --step-3: clamp(1.73rem, calc(1.32rem + 2.05vw), 2.96rem);
  --step-4: clamp(2.07rem, calc(1.45rem + 3.12vw), 3.95rem);
}

The above is much easier to parse, but the calc parts present a mystery. Using these type scales is thankfully easy:

body { font-size: 100%; }
h1 {
    font-size: var(--step-3);
    line-height: 1.1;
}
h2 {
    font-size: var(--step-2);
    line-height: 1.2;
}
p {
    font-size: var(--step-0);
    line-height: 1.5;
}

A Fluid type scale without media queries!

No perfect Sizes.

A key tenet of fluid type is that there are no perfect font sizes. Which is pretty rad when you think about it. What matters is the relationship of the type sizes to one another, and the intended maximum and minimum size. When you don't have to worry about perfect type sizes, you're allowed to think in more abstract, role based ways. Is this a Heading? or a SubHeading? Content text or a blockquote? Should it be large, or small. By excising pixel perfect requirements for our text we instead have text with perfect, or intended relationships. It's these relationships that we care about. Once again to add emphasis and hierarchy to the page. Implicit Harmony.

The best time to adopt a fluid type scale is during a redesign or new site buildout. A refactor is also a good time. Adopting fluid type will make documenting and managing a design system much easier. You can lean on the intended type sizes in your components, and quickly build relationships between your content and compnents.

If you've been hesitant to try fluid type before I encourage you to adopt it. It kicks ass and will make your websites look very Schway.

Karl Oscar Weber October 07, 2022

Ruby Camping

Hi Friends,

Camping is a micro web-framework written in Ruby. Originally written by _why the lucky stiff, (Their real name), Camping was a pretty popular framework a few years ago, but over time just slowed down. Now Camping is actively maintained and improving.

One of the best things about Camping is how compact it is, The whole thing is about 4kb:

require"uri";require"rack";E||="Content-Type";Z||="text/html"
class Object;def meta_def m,&b;(class<<self;self
end).send:define_method,m,&b end;end;module Camping;C=self;S=IO.read(__FILE__
)rescue nil;P="<h1>Cam\ping Problem!</h1><h2>%s</h2>";U=Rack::Utils;O={url_prefix:""};Apps=[];
SK=:camping;G=[];class H<Hash;def method_missing m,*a;m.to_s=~/=$/?self[$`]=a[0]:a==[]?self[m.
to_s]:super end;undef id,type if ??==63 end;class Cookies<H;attr_accessor :_p;
def _n;@n||={}end;alias _s []=;def set k,v,o={};_s(j=k.to_s,v);_n[j]=
{:value=>v,:path=>_p}.update o;end;def []=(k,v)set(k,v,v.is_a?(Hash)?v:{})end
end;module Helpers;def R c,*g;p,h=
/\(.+?\)/,g.grep(Hash);g-=h;raise"bad route"if !u=c.urls.find{|x|break x if
x.scan(p).size==g.size&&/^#{x}\/?$/=~(x=g.inject(x){|x,a|x.sub p,U.escape((a.
to_param rescue a))}.gsub(/\\(.)/){$1})};h.any?? u+"?"+U.build_query(h[0]):u
end;def / p;p[0]==?/?@root+p : p end;def URL c='/',*a;c=R(c,*a) if c.respond_to?(
:urls);c=self/c;c=@request.url[/.{8,}?(?=\/|$)/]+c if c[0]==?/;URI c end end
module Base;attr_accessor:env,:request,:root,:input,:cookies,:state,:status,
:headers,:body;T={};L=:layout;def lookup n;T.fetch(n.to_sym){|k|t=Views.
method_defined?(k)||(t=O[:_t].keys.grep(/^#{n}\./)[0]and Template[t].new{
O[:_t][t]})||(f=Dir[[O[:views]||"views","#{n}.*"]*'/'][0])&&Template.
new(f,O[f[/\.(\w+)$/,1].to_sym]||{});O[:dynamic_templates]?t: T[k]=t} end
def render v,*a,&b;if t=lookup(v);r=@_r;@_r=o=Hash===a[-1]?a.pop: {};s=(t==true)?mab{
send v,*a,&b}: t.render(self,o[:locals]||{},&b);s=render(L,o.merge(L=>false)){s
}if o[L]or o[L].nil?&&lookup(L)&&!r&&v.to_s[0]!=?_;s;else;raise"no template: #{v}"
end;end;def mab &b;extend(Mab);mab(&b) end;def r s,b,h={};b,h=
h,b if Hash===b;@status=s;@headers.merge!(h);@body=b end;def redirect *a;r 302,
'','Location'=>URL(*a).to_s end;def r404 p;P%"#{p} not found"end;def r500 k,m,e
raise e end;def r501 m;P%"#{m.upcase} not implemented"end;def serve(p,c)
(t=Rack::Mime.mime_type p[/\..*$/],Z)&&@headers[E]=t;c;end;def to_a;@env[
'rack.session'][SK]=Hash[@state];r=Rack::Response.new(@body,@status,@headers)
@cookies._n.each{|k,v|r.set_cookie k,v};r.to_a end;def initialize env,m
r=@request=Rack:: Request.new(@env=env);@root,@input,@cookies,@state,@headers,
@status,@method=r.script_name.sub(/\/$/,''),n(r.params),Cookies[r.cookies],
H[r.session[SK]||{}],{E=>Z},m=~/r(\d+)/?$1.to_i: 200,m;@cookies._p=self/"/" end
def n h;Hash===h ?h.inject(H[]){|m,(k,v)|m[k]=
n(v);m}: h end;def service *a;r=catch(:halt){send(@method,*a)};@body||=r;self
end end;module Controllers;@r=[];class<<self;def R *u;r=@r;Class.
new{meta_def(:urls){u};meta_def(:inherited){|x|r<<x}}end;
def v;@r.map(&:urls);end;def D p,m,e;p='/'if
!p||!p[0];(a=O[:_t].find{|n,_|n==p}) and return [I,:serve,*a]
@r.map{|k|k.urls.map{|x|return(k.method_defined? m)?[k,m,*$~[1..-1].map{|x|U.unescape x}]:
[I, 'r501',m]if p=~/^#{x}\/?$/}};[I,'r404',p] end;
module F;A= ->(c,u,p){u.prepend("/"+p) unless c.to_s == "I"}end;N=H.new{|_,x|x.downcase}.
merge!("N"=>'(\d+)',"X"=>'([^/]+)',"Index"=>'');def M(pr);def M(pr);end;constants.
map{|c|k=const_get(c);k.send:include,C,X,Base,Helpers,Models
@r=[k]+@r if @r-[k]==@r;k.meta_def(:urls){[F::A.(k,"#{c.to_s.scan(/.[^A-Z]*/)
.map(&N.method(:[]))*'/'}",pr)]}if !k.respond_to?:urls}end end;I=R()end;X=
Controllers;class<<self;def routes;X.M O[:url_prefix];(Apps.map(&:routes)<<X.v).flatten;end;
def call e;X.M O[:url_prefix];k,m,*a=X.D e["PATH_INFO"],e['REQUEST_METHOD'].
downcase,e;k.new(e,m).service(*a).to_a;rescue;r500(:I,k,m,$!,:env=>e).to_a end
def method_missing m,c,*a;X.M O[:url_prefix];h=Hash===a[-1]?a.pop: {};e=H[Rack::MockRequest.
env_for('',h.delete(:env)||{})];k=X.const_get(c).new(e,m.to_s);h.each{|i,v|k.
send"#{i}=",v};k.service(*a) end;def use*a,&b;m=a.shift.new(method(:call),*a,&b)
meta_def(:call){|e|m.call(e)}end;def pack g, *a, &b;G<<g;include g;
extend g::ClassMethods if defined?(g::ClassMethods);g.setup(self)if g.respond_to?(:setup)end;
def gear;G end;def options;O end;def set k,v;O[k]=v end
def goes m,g=TOPLEVEL_BINDING;Apps<<a=eval(S.gsub(/Camping/,m.to_s),g);caller[0]=~/:/
IO.read(a.set:__FILE__,$`)=~/^__END__/&&(b=$'.split /^@@\s*(.+?)\s*\r?\n/m).shift rescue nil
a.set :_t,H[*b||[]];end;end
module Views;include X,Helpers end;module Models;autoload:Base,'camping/ar'
Helpers.send:include,X,self end;autoload:Mab,'camping/mab'
autoload:Template,'camping/template';C end

Because Camping is intended to be as compact as possible, single file apps are encouraged. Which is pretty cool.

Camping.goes :Nuts

module Nuts
  module Controllers
    class Index
      def get
        render :index
      end
    end
  end
  module Views
    def index
      h1 'Hello World'
    end
  end
end

Also because single file apps are a thing, more than one "app" can be mounted together:

Camping.goes :Nuts # Nuts app is mounted.
# ... Nuts module here

Camping.goes :Blog # Blog app is mounted.
# ... Blog module here

A Camping app is just a module mounted within a namespace, either the global namespace, or another app's namespace. This makes distributing an app via RubyGems pretty easy too.

Camping's default view architecture uses MAB which is an HTML generator in Ruby.

module Views
  def index
    if @posts.empty?
      h2 'No posts'
        p do 
          text 'Could not find any posts. Feel free to '
          a 'add one', :href => R(PostNew)
          text ' yourself'
        end
    else
      @posts.each do |post|
        _post(post)
      end
    end
  end
end

I've been updating Camping to have better database support. It comes with built in support for ActiveRecord, but what about other database engines? Through a new plugin system called gear, I'm adding support for different database systems. In the next version the built in ActiveRecord integration is being moved to some Camping Gear named GuideBook:

require 'camping'
require 'guidebook' # Guidebook adds ActiveRecord to Camping.

Camping.goes :Nuts

module Nuts

  # In Camping you Pack Gear.
  pack Camping::GuideBook

  module Models
    class Page < Base; end
  end

  def self.create
    # establishes a database connection when the app is created.
    establish_connection()
  end
  # ... Controllers, Views, Helpers.
end

Camping has some tricks up it's sleeves. Like adding styles and other files to the end of your camping code:

# ... The rest of your camping app up here

__END__

@@ /style.css
* { margin: 0; padding: 0 }

Camping is based on Rack so adding middleware is pretty simple:

require 'camping'
require 'warden'

module Nuts
  
  use Warden::Manager do |manager|
    manager.default_strategies :password, :token
    manager.failure_app = BadAuthenticationEndsUpHere.new
  end
  
end

What's next for Camping?

Camping is mostly just plain old ruby with some funny bits. But it's so interesting how all the pieces fit together. It's so small and compact you can read the whole source code in a few minutes, but it's packed with interesting Ruby tricks that truly stretch what you can do with Ruby.

I began looking for a new web framework in early 2022, I found Camping to be interesting and exactly what I was looking for. Small, Simple, and stuck in a single file. Unmaintained for 6 years it didn't work right away, but after a little bug fixing it was good as new. Working on Camping has taught me so much about Ruby. It's absolutely been worth every moment.

I think that the future of Camping is to keep the core framework as small as possible, but make it easy to extend. Things like new view systems, database ORMs, or even websockets. The next version of Camping will have a decoupled, yet improved database plugin called Guidebook, A Camping NEW command line helper, and documentation improvements. Soon I'll add support for websockets, Phlex Views, the Falcon webserver, Rack3, and the Sequel database toolkit, configurations using a kdl config file, and asynchronous code execution. In particular I'm very interested in making the developer experience as fantastic as possible. To me that means inspection and testing tools. Amazing and detailed Documentation. Plus common helpers to make difficult tasks very simple to understand and perform.

Working on Camping has made me very excited about my career again. I really love it.