Karl Oscar Weber November 10, 2014

Lessons Learned Writing Swift Foundations

A couple of months ago I started a pretty ambitious project, A programming book for Beginners: Swift Foundations. I also began working on a new podcast for this blog. Doing both at once was a bad move and my expectations for both projects were far below what they turned out to be.

I bit off more than I could chew. The Book ballooned from something simple to a directionless wreck. It was riddled with what looked like GOTO statements touching on every programming topic imaginable, I would add a chapter about almost anything. I had a full time job, A budding family, a Podcast to Spin up, and now a colossal book, Spreading myself so thin made everything suffer. It was an unfocused mess. I threw most of it out and started over.

I got distracted with this tiered pricing strategy with bonus content, videos, and sample apps. Eventually I remembered that I didn't want to write books, I wanted to make apps. I just want to write one simple book for beginners, not juice them for cash or become an independent author. Not that there is anything wrong with that, it's just not what I want to do. I want something Small, Focused, and Cheap.

Fewer Chapters made my book BETTER.

I Hit Reboot on my book by focusing on the essential concepts. I dropped the chapter count from 26 down to 6. I took a lesson from my own experience trying to learn to program PHP from a book. I learn best when I have a couple key concepts to practice before I move on to something new. This lesson was completely absent from Swift Foundations, I was teaching too much in a shallow manner It just wasn't a beginner friendly book.

Focus on the Basics

Focusing was the best thing I ever did. It was always supposed to be focused on the basics. Each Chapter teaches a couple core concepts in a relatable and comprehensive way. A quick explanation is given for concepts that aren't necessary to build the app. Core concepts, like the fact that data can be stored (which is earth shattering when you really think about it) are explained and demonstrated in various ways to ensure comprehension.

Show, Don't Tell.

Lots of examples are better than lots of explanation. A picture is worth a thousand words, but so is a block of code. The code to Text ratio in the book is about 60% text to 40% code, Just enough explanation to describe exactly what the code does. There are also examples of what not to do, incorrect syntax, or tricky situations to avoid. Warning signs are there. Enough Screenshots to paint a complete picture of what you'll build. Most of the chapters build a piece of the app step by step so that you won't get lost along the way.

Karl Oscar Weber February 28, 2024

Capsule

In January 2024, I was laid off. It was sudden, and extremely rude. I found out during standoff. Soon after my work accounts stopped working. I had poured so much into that job. The people, and the environment. I worked really hard to make it a great place for the folks on the team, and to support them any way that I could. But all for naught.

That's alright, time to learn and move forward. I spent a couple of weeks trying to figure out what was next for me. What am I really good at and what do I want to do? You know, besides the necessity to pay for rent, utilities, and food. Also I have a wife and 4 kids. Gotta provide for them too. It's kinda important.

After a while I figured out what I wanted to do. Everything.

Everything?

Friends, I'm serious. I really like Art and Design stuff, been doing it on the side for like 20 years. Over the last couple of years I've gone through an existential change in how I see things. "Why the fuck not?!?!" Is often going through my mind. I'm more confident than I've ever been and it fucking shows. I'm just getting better at my job.

So the thing I want to do for the next 40 years is a subscription studio. I call it Capsule.

Capsule is everything

There's been this concept going around of agencies or studios delivering unlimited design services for a flat monthly fee. A retainer basically, but not really. It's a subscription. Usually a subscriber is limited to one "request" or task at a time. So that the provider of services can rotate through their clients, Deliver value, then await for feedback.

I think this model is pretty cool. Paid upfront, the price is low enough that it can be a subscription, and all the work I can handle. It's pretty swell. Actually.

The only way to get better/faster.

Is to do more work. That's it. Quantity == Quality. Rise and Grind my friends. I'm pretty good at my job, but I want to be even better. Fast and Furious. The only path I see to doing that is straight through. Do as much work as I can, as fast as I can. So that's what Imma do.

Capsule has 3 plans, Rocket, Pro, and Bell Grande. The Rocket plan offers Art, Design, and websites. That's front end work writing HTML and CSS. Pro Also offers Ruby and iOS development, and Bell Grande is just 3 times bigger than Pro. It's like having a small startup team working for you furiously. The prices are $999, $1,999, and $5,999. But all the plans are 50% off for the first 10 customers or until the launch month ends, whichever comes first. So it's way cheaper and it's like an 83% discount off my normal rate. It would be crazy not to subscribe, CRAZY! The discount lasts until you cancel. It's that simple.

Anyways friends. That's what I'm doing. Capsule, Get some.

Karl Oscar Weber September 05, 2023

I started writing a programming language

Hi friends,

I started writing a programming language in Lua. Lua is fast, small, embeddable, extendable, and has a Garbage Collector. I want to write something that is simple to parse, extensible, and purpose built for writing and working with UI on the web.

Originally I wanted to dig deep into coffeescript to figure this out, I still might do that, but CoffeeScript has a syntax that irks me. I wondered if it would be easy enough to write an interpreter that compiles to another language. Like CoffeeScript to Javascript. I figured that it's gotta be possible, Right? I mean, people have DONE this before. But the issues I have is that CoffeeScript IS Javascript with a mask on and some bits hidden/removed. I want to make something that kinda starts from scratch, Fresh and new with some lessons.

WASM is a thing. So why not write a language that's embedded in your browser? That could be cool right? I'd love to just ship my programming languages files like javascript files, or write it directly on my website, and see it just work. Try to bring some of that magic back. With a stable WASM interpreter I could push that to a CDN and then folks hitting the pages with this language would only need to download the interpreter once.

What's next?

Well, I guess I need to get the basics of the thing working. An interpreter, some Variables, math, and a REPL. Follow along here: https://github.com/karloscarweber/stim

Karl Oscar Weber March 07, 2023

So you want Ruby to grow?

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.