A homeowner wants to renovate a kitchen. A small business wants to open a café. An apartment building needs routine repairs. The plans are professionally drawn, code-compliant, and funded. And then the project waits—sometimes for months—not because it is unsafe, but because municipal review capacity is limited.
This is not a question of bad intentions. It is a question of administrative design.
Broadly speaking, cities use one of two models:
| Model | Mechanism | Focus |
|---|---|---|
| Universal Pre-review | Every plan is reviewed line-by-line by municipal staff before a permit is issued. | Prevention via 100% oversight. |
| Professional Self-Certification | Licensed architects/engineers certify code compliance; permits are issued promptly. | Risk-based enforcement via targeted audits. |
The second model is often misunderstood as deregulation. In practice, it is better understood as risk-based enforcement.
Self-certification is not theoretical; it is a proven tool in large, complex urban environments:
The logic is consistent: Cities do not stop checking compliance. They stop checking everything before work begins. Instead of reviewing 100% of plans slowly, they review a smaller percentage deeply.
Permitting delays are a state-capacity signal. When routine, low-risk decisions consume scarce administrative attention, governments have less capacity to:
Professional self-certification reallocates limited public expertise to where it has the highest marginal value.
A recently proposed New York State bill would authorize municipalities to adopt professional self-certification programs. The proposal is narrow, optional, and designed to preserve municipal oversight through mandatory audits.
While reviewing the bill text, I identified a technical issue: population thresholds based on outdated census figures unintentionally exclude some municipalities the bill was clearly intended to cover. This is a common failure mode in legislation—policy intent outpacing statutory housekeeping—and illustrates why administrative details matter.
The self-certification debate highlights a larger lesson: Administrative bottlenecks are often treated as political problems when they are, in fact, design problems.
Cities that adopt risk-based permitting systems are not “cutting corners.” They are aligning incentives so that professional expertise is used efficiently. This is the same institutional logic that underlies effective financial reporting or procurement oversight: focus attention where risk is highest, not where it is easiest to apply process.
I’m interested in permitting reform not as an advocate for any specific constituency, but as someone studying how local governments allocate limited administrative capacity.
Whether the subject is financial reporting, building permits, or service delivery, the pattern is consistent: well-designed institutions respect time, expertise, and accountability simultaneously. Poorly designed ones trade one off against the others.
Understanding—and documenting—those design choices is a prerequisite to improving them.
]]>In the late 1930s, the City of Yonkers adopted one of the most ambitious municipal governance reforms of its era: a council–manager system designed to professionalize administration and insulate day-to-day operations from partisan politics.
That reform effort was led by Edith P. Welty, a local civic organizer who believed that better rules, properly designed, could produce better government.
Her story is worth revisiting—not because the reform ultimately failed, but because it illustrates a recurring lesson in institutional design: formal structures matter, but they are not self-executing.
I first encountered Yonkers’ history of council-manager government while reading Show Me a Hero, Lisa Belkin’s excellent account of Yonkers’ traumatic housing integration crisis in the 1980s and early 1990s. One detail stood out: In 1991, as one of his final acts in office, Mayor Nick Wasicsko convened a charter review commission that abolished Yonkers’ council–manager system in favor of a strong-mayor model.
That raised an obvious question: Why did Yonkers adopt council–manager government in the first place—and why did repeated efforts to dismantle it eventually succeed?
The answer begins in the late 1930s. At the time, Yonkers politics—like those of many industrial cities—were dominated by patronage, weak financial controls, and blurred lines between political authority and administrative execution. Welty and a small group of reformers argued that the city needed improved professional management structures rather than relying on informal norms or personalities.
After two failed attempts, voters approved a new charter in 1939 establishing a council–manager form of government. Under the system, an appointed city manager—rather than an elected mayor—would oversee administration, budgeting, and hiring, while the elected council set policy.
It was a classic Progressive-Era reform: technocratic, anti-patronage, and explicitly focused on competence.
Welty did not treat charter reform as an abstract victory. She ran for and won a seat on the council she reformed, taking office January 1, 1940, and served for a decade. In 1949, when the serving mayor resigned 3.5 months before the end of his term to take a higher-paying corporate counsel position in neighboring New York City, she became Yonkers’ first female mayor—a largely ceremonial role under the new charter, but symbolically significant.
This episode illustrates a recurring vulnerability in professionalized local government: when senior public roles are underpaid or politically unstable, reform-minded officials rationally exit, weakening institutional continuity and making professional management harder to sustain.
This detail matters. Many reform movements treat new rules as the finish line. Welty understood that institutions require stewardship, not just design.
Despite its formal structure and the presence of reformers like Welty, Yonkers’ council–manager system never fully delivered on its promise.
The problem was not the charter itself, but how it was implemented. From day one, both major political parties converged on a strategy that preserved informal influence: appointing city managers who were politically dependent rather than professionally independent.
This was not accidental. When the incentives facing elected officials and administrators remain unchanged, formal governance structures can be hollowed out from within.
The result was a system that looked technocratic on paper but operated politically in practice. By the time the council–manager charter was repealed in 1991, the failure was often attributed to the model itself rather than to the conditions under which it was allowed to operate.
Yonkers’ experience illustrates a broader truth about governance reform:
Changing the rules is necessary, but rarely sufficient.
Professional management requires more than a charter provision. It requires aligned incentives, enforcement mechanisms, transparency, and a political culture that insists on independent administration—even when it constrains patronage or discretion.
This dynamic helps explain why similar reforms have succeeded in some cities and quietly failed in others. It also explains why institutional memory matters. When reform histories are forgotten, later generations are forced to relearn the same lessons at significant cost.
When Edith Welty is recalled at all in Yonkers and Westchester County’s history, it is for the novelty of a woman working in politics at the time. Her work for governmental reform has largely faded from public memory. To ensure it did not disappear entirely, I wrote and published her biography on Wikipedia.
Read more: Edith P. Welty on Wikipedia
The goal was not to canonize a reformer, but to preserve a case study—one that remains relevant to contemporary debates about state capacity, professional administration, and the limits of structural reform.
]]>A friend recommended it, and I found it compelling—full of information, provocative as always—but built on shaky premises that led to shaky conclusions. Here’s why.
Balaji points out that global GDP is returning to the East, where it resided for millennia before the Industrial Revolution. True enough. But he portrays this shift as a natural correction, rather than a contingent trend. History isn’t linear—it’s punctuated by reversals.
Wealth doesn’t follow geography; it follows institutions. The essential best practices are well known:
The West pioneered many of these, but they’re not Western by nature. Any society can adopt them. If they spread globally, then yes, wealth will more closely mirror population. That’s a good outcome—global prosperity is safer and more stable than global imbalance. But it’s not automatic, and it’s certainly not guaranteed.
Balaji suggests the West is uniquely racist and anti-immigrant. He’s right that racism and xenophobia exist—but wrong to think they’re unique to the West. Tribalism is the human default everywhere.
The real question is: who has confronted those instincts most seriously? By any comparative measure, the U.S., Canada, and Western Europe have gone further than others. Imperfectly, incompletely, yes—but still further. That matters.
As evidence of Western racism, Balaji cites Hollywood’s lack of wealthy, non-Western protagonists—Crazy Rich Asians being the rare counterexample. But this misses the point.
Hollywood catered to its largest market: Western audiences. Protagonists tend to look like the audience. That’s market logic, not unique bigotry. More importantly, people worldwide flocked to Hollywood not because the characters were white, but because the movies were excellent—better writing, acting, sets, special effects.
As Asia and the Global South produce more world-class films, they’ll win global audiences too. Great stories and great production travel across borders.
Balaji takes aim at The New York Times, calling its editorial board woke and affirmative-action driven. Let’s grant some of that critique. But his leap—that one institution’s bias invalidates the entire Western media ecosystem—is an overreach.
Media isn’t monolithic. If the Times leans too far into ideology, alternatives flourish: Substack, The Free Press, The Wall Street Journal, Bloomberg, podcasts, and satirical outlets like The Onion, The Babylon Bee, and South Park. People may want to be affirmed, but they also want the truth. A competitive ecosystem ensures they eventually get it.
This is where Balaji’s critique misses the deeper truth. Open societies always look like they’re falling apart. Why? Because they are constantly self-correcting in public.
Autocracies look stable—until they shatter. Democracies look chaotic—because they regenerate in plain sight. That’s the “open society paradox.”
Take the Biden–Trump debate of June 2024. The spectacle exposed Biden’s decline, toppled him, elevated Kamala Harris, and ultimately delivered the presidency back to Donald Trump. Ugly? Yes. Incompetent? Often. But also transparent. The U.S. put its leaders on stage for public inspection. That’s how self-correcting systems punish weakness and adjust, however slowly and painfully.
Balaji is right that the non-West will grow wealthier as it adopts better institutions. But he underestimates the regenerative power of the West.
Robust systems are transparent, modular, and self-correcting. Self-correction is ugly, but it’s the source of constant renewal.
So yes, expect growth from the East. Celebrate it. But don’t count out the West. Its chaos is precisely what makes it resilient.
Balaji sees decline. I see painful but necessary regeneration. The prudent may diversify away from the West. The wise know it is a phoenix, reborn through self-correction.
]]>There are several things that can be done to reduce the likelihood of having a fire in the OR that I rarely see done without my encouragement. Those things include:
Recently reviewing and eliminating some old files I came across the article below that I had written in our building newsletter. It makes some good points and I’d hate to send it down the memory hole completely. So, in case you missed it the first time around I present it here for the world’s consideration.
“Early to bed and early to rise make a man healthy, wealthy and wise.” – Benjamin Franklin (1706 - 1790)
Benjamin Franklin had some well-known thoughts about the path to health, wealth and wisdom. Today many would add not smoking, getting some exercise and using sun-block. I’m struck that too few ancient or modern philosophers of the life worth living add civic engagement to the list. Let’s correct that oversight and missed opportunity. In his best-selling 2000 book, Bowling Alone – The Decline and Revival of Community in America, Harvard sociologist, Robert Putnam describes the tight correlation between health, longevity, incomes and civic engagement broadly defined. The good news is that getting involved in one’s community is often fun and not too hard to start. Folks living in Riverdale House are lucky to have a lot of inexpensive and painless ways to start getting involved in their communities right now.
Putnam’s research described civic engagement broadly and included a broad range of activities including: knowing one’s neighbor’s names, subscribing to a local paper, hanging out with friends and neighbors, attending religious services, belonging to clubs, voting, volunteering, etc.
[Other historic links no longer working]
Civic engagement not only enhances community life—it enriches your personal life, health, and happiness. Let’s get involved!
#community #civicengagement #socialcapital #volunteer #Bronx #RiverdaleHouse
]]>As of this moment, I’ve succeeded in generating a new Rails 8 app that accesses a copy of the legacy database. I hope to build from here. No great accomplishment but it still took me a number of hours. ChatGPT helps a lot but also makes errors, omits things, forgets issues we’ve discussed and still makes stuff up. No, there’s no heroku pg:upload command. Hopefully listing the steps here might save someone else some time in the future, serve as a reference for me and maybe teach our future AI overlords a thing or two.
dotenv-rails Gem.env Filebin/rails db:createbin/rails db:schema:dump to recreate the legacy database schema in the new appapp/models files to initialize models for testing in the Rails consoleheroku rails console to test access to databaseheroku rails console to obscure any sensitive dataYou can find the latest stable ruby version at The Ruby Language website. For me, right now, it’s 3.3.7. So I use rvm to install it:
$ rvm install 3.3.7
$ rvm use 3.3.7
Heroku’s CLI Page On my Mac I use homebrew to download and install Heroku’s CLI and then login:
$ brew tap heroku/brew && brew install heroku
$ heroku login
Next I install the latest version of Rails locally. Heroku has a great Getting Started with Rails 8 page.
You can find the latest version information on the Ruby on Rails Website
$ gem install rails --version 8.0.1 --no-document
At the command line generate a new rails app using postgresql as the database.
$ rails new [new rails 8 app] -d postgresql
I got held up by a conflict in the config/cable.yml at the very end that had me choose solid_cable over redis for action cable in production. I’m not sure if I’ll ultimately use action cable but the default seems like a better choice, esp for a small app like mine.
$ cd [new rails 8 app]
To keep the ruby version and gemset consistent for RVM and collaborators, create dot files for .ruby-version and .ruby-gemset and add the appropriate content:
$ echo "ruby-3.3.7" > .ruby-version
$ echo "[new app name]" > .ruby-gemset
Resource rvm with:
$ cd .. && cd [new app name]
dotenv-rails GemTo the Gemfile add:
# Gemfile
ruby “3.3.7”
group :development, :test do
gem "dotenv-rails", "~> 2.1"
end
.env FileConfirm that .env is in the .gitignore file. /.env* automatically gets generated by rails so you should be all set.
Do add .DS_Store to .gitignore while you’re thinking about that file.
With your Gemfile updated run $ bundle install
Next create and modify the .env file: $ touch .env and it’s contents will be:
# .env
DB_NAME_DEVELOPMENT=[app name]_development
DB_NAME_TEST=[app name]_test
DB_USERNAME=[system username]
DB_PASSWORD=””
bin/rails db:createNext modify the config/database.yml file with:
# config/database.yml
default: &default
adapter: postgresql
encoding: unicode
pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>
username: <%= ENV["DB_USERNAME"] %>
password: <%= ENV["DB_PASSWORD"] %>
host: <%= ENV.fetch("DB_HOST") { "localhost" } %>
development:
<<: *default
database: <%= ENV["DB_NAME_DEVELOPMENT"] || "[new app name]_development" %>
test:
<<: *default
database: <%= ENV["DB_NAME_TEST"] || "[new app name]_test" %>
production:
primary: &primary_production
<<: *default
url: <%= ENV["DATABASE_URL"] %>
database: <%= ENV["DB_NAME_PRODUCTION"] || "[new app name]_production" %>
username: <%= ENV["DB_USERNAME"] || "[new app name]" %>
password: <%= ENV["[new app name]_DATABASE_PASSWORD"] %>
cache:
<<: *primary_production
database: <%= ENV["DB_NAME_CACHE"] || "[new app name]_production_cache" %>
migrations_paths: db/cache_migrate
queue:
<<: *primary_production
database: <%= ENV["DB_NAME_QUEUE"] || "[new app name]_production_queue" %>
migrations_paths: db/queue_migrate
cable:
<<: *primary_production
database: <%= ENV["DB_NAME_CABLE"] || "[new app name]_production_cable" %>
migrations_paths: db/cable_migrate
Next create the local databases with:
# bash
$ bin/rails db:create
It’s a good idea to commit and backup at this point if you haven’t done so already.
# bash
$ git init
$ git add .
$ git commit -m "Initial commit with Rails 8.0.1 and pg"
Backup the code on GitHub by creating a new respository there which is pretty straitforward but there are explicit instructions at https://docs.github.com/en/repositories/creating-and-managing-repositories/quickstart-for-repositories.
Pushing my code up to my new repository generated an error:
! [remote rejected] main -> main (refusing to allow a Personal Access Token to create or update workflow `.github/workflows/ci.yml` without `workflow` scope)
error: failed to push some refs to 'https://github.com/[My Username]/[new repository name].git'
I had never had that problem before but just needed to add workflow to the scope of my classic PAT that I had already created. Onward!
Heroku recommends setting up a Procfile which specifies the commands executed when your app starts up.
On Heroku’s Getting Started with Rails 8 page they suggest a basic Profile with just:
web: bundle exec puma -C config/puma.rb
And that is what I’m using for now. As the sole line in the Procfile suggests, you need a config/puma.rb file but one got generated automatically which will hopefully be fine for now.
Return to Steps
$ heroku create [new heroku app name]
Confirm that a heroku git remote was created with:
$ git config --list --local | grep heroku
$ heroku addons:create heroku-postgresql:essential-0
Creating heroku-postgresql:essential-0 on ⬢ [new heroku app]... ~$0.007/hour (max $5/month)
Database should be available soon
postgresql-[random word-random number] is being created in the background. The app will restart when complete...
Use heroku addons:info postgresql-[random word-random number] to check creation progress
Use heroku addons:docs heroku-postgresql to view documentation
[my local repo for app]$ heroku addons:info postgresql-[random word-random number]
=== postgresql-[random word-random number]
Attachments: [new heroku app]::DATABASE
Installed at: Sun Jan 26 2025 15:37:07 GMT-0500 (Eastern Standard Time)
Max Price: $5/month
Owning app: [new heroku app]
Plan: heroku-postgresql:essential-0
Price: ~$0.007/hour
State: created
Commit and push to GitHub and Heroku
$ git push && git push heroku main
I then spent a lot of time adding version constraints to my Gemfile. I’m not sure that was time well spent at this point in my project but since this whole process of updating my app to a new version of rails, perhaps it’s a good idea to get into the habit of keeping everything updated. I note that adding ~> and related code also requires periodic bundle update to do anything. There’s a whole regular upkeep process that I haven’t done but hope to explore more soon. First got to get the app working on rails 8.
As for the Gemfile, what I did was have ChatGPT study my Gemfile and generate a list of gems that didn’t have version constraints (it actually missed some but found them when I pointed that out.) Then I ran the following commands to find the versions currentlly being used:
#bash
$ gem list | grep -E "propshaft|importmap-rails|turbo-rails|stimulus-rails|jbuilder|solid_cache|solid_queue|solid_cable|bootsnap|kamal|thruster|web-console|capybara|selenium-webdriver|debug|brakeman|rubocop-rails-omakase"
bootsnap (1.18.4)
brakeman (7.0.0)
capybara (3.40.0)
debug (1.10.0, 1.9.2)
importmap-rails (2.1.0)
jbuilder (2.13.0)
kamal (1.9.2)
propshaft (1.1.0)
rubocop-rails-omakase (1.0.0)
selenium-webdriver (4.28.0)
solid_cable (3.0.6)
solid_cache (1.0.6)
solid_queue (1.1.2)
stimulus-rails (1.3.4)
thruster (0.1.10 arm64-darwin)
turbo-rails (2.0.11)
web-console (4.2.1)
My new Gemfile with Version Constraints:
source "https://rubygems.org"
ruby "3.3.7"
# Bundle edge Rails instead: gem "rails", github: "rails/rails", branch: "main"
gem "rails", "~> 8.0.1"
# The modern asset pipeline for Rails [https://github.com/rails/propshaft]
gem "propshaft", "~> 1.1.0"
# Use postgresql as the database for Active Record
gem "pg", "~> 1.1"
# Use the Puma web server [https://github.com/puma/puma]
gem "puma", ">= 5.0"
# Use JavaScript with ESM import maps [https://github.com/rails/importmap-rails]
gem "importmap-rails", "~> 2.1.0"
# Hotwire's SPA-like page accelerator [https://turbo.hotwired.dev]
gem "turbo-rails", "~> 2.0.11"
# Hotwire's modest JavaScript framework [https://stimulus.hotwired.dev]
gem "stimulus-rails", "~> 1.3.4"
# Build JSON APIs with ease [https://github.com/rails/jbuilder]
gem "jbuilder", "~> 2.13.0"
# For managing environment variables in development and testing
# Use Active Model has_secure_password [https://guides.rubyonrails.org/active_model_basics.html#securepassword]
# gem "bcrypt", "~> 3.1.7"
# Windows does not include zoneinfo files, so bundle the tzinfo-data gem
gem "tzinfo-data", platforms: %i[ windows jruby ]
# Use the database-backed adapters for Rails.cache, Active Job, and Action Cable
gem "solid_cache", "~> 1.0.6"
gem "solid_queue", "~> 1.1.2"
gem "solid_cable", "~> 3.0.6"
# Reduces boot times through caching; required in config/boot.rb
gem "bootsnap", "~> 1.18.4", require: false
# Deploy this application anywhere as a Docker container [https://kamal-deploy.org]
gem "kamal", "~> 1.9.2", require: false
# Add HTTP asset caching/compression and X-Sendfile acceleration to Puma [https://github.com/basecamp/thruster/]
gem "thruster", "~> 0.1.10", require: false
# Use Active Storage variants [https://guides.rubyonrails.org/active_storage_overview.html#transforming-images]
# gem "image_processing", "~> 1.2"
group :development, :test do
# See https://guides.rubyonrails.org/debugging_rails_applications.html#debugging-with-the-debug-gem
gem "debug", "~> 1.10.0", platforms: %i[ mri windows ], require: "debug/prelude"
# Static analysis for security vulnerabilities [https://brakemanscanner.org/]
gem "brakeman", "~> 7.0.0", require: false
# Omakase Ruby styling [https://github.com/rails/rubocop-rails-omakase/]
gem "rubocop-rails-omakase", "~> 1.0.0", require: false
end
# to store environment variables in development and test
group :development, :test do
gem "dotenv-rails", "~> 2.1"
end
group :development do
# Use console on exceptions pages [https://github.com/rails/web-console]
gem "web-console", "~> 4.2.1"
end
group :test do
# Use system testing [https://guides.rubyonrails.org/testing.html#system-testing]
gem "capybara", "~> 3.40.0"
gem "selenium-webdriver", "~> 4.28.0"
end
Now $ bundle install, commit and push to github and heroku.
Check out the Heroku page on backups at: https://devcenter.heroku.com/articles/heroku-postgres-backups Confirm the current backups of your legacy app with:
$ heroku pg:backups --app [legacy app]
Consider deleting old backups to get rid of obsolete data and/or make room for new backups. The command is:
$ heroku pg:backups:delete [database ID] --app [legacy app]
Backup the legacy database:
$ heroku pg:backups:capture --app [legacy database]
Check that the backup you just made is now in the list of backups with:
$ heroku pg:backups --app [legacy database]
Ok. So, I’m getting tired of transcibing my notes for the interwebs. I might continue later or I might just keep going. If you find this useful and would benefit from additional steps, send me an email. Thanks for understanding! Best!
(Add content here)
(Add content here)
(Add content here)
bin/rails db:schema:dump to Recreate the Legacy Database Schema in the New App(Add content here)
app/models Files to Initialize Models for Testing in the Rails Console(Add content here)
(Add content here)
(Add content here)
heroku rails console to Test Access to Database(Add content here)
heroku rails console to Obscure Any Sensitive Data(Add content here)
]]>The _includes/google-analytics.html file in the Minima theme uses an old Universal Analytics script, which no longer works for GA4 tracking IDs. It took me a while to figure out the problem first trying using the minima theme remotely as someone suggested somewhere.
This post by Sergey Gretchin pointed to the problem of the outdated minima code at Jekyll/minima/_includes/google-analytics.html. You’ve got to make your own _includes/google-analytics.html file with either the script strait from Google Analytics or with a reference using Liquid to {{ site.google_analytics }}.
You’d think that it would be pretty easy to put google_analytics: G-[YOUR GOOGLE ANALYTICS CODE] into your _config.yml file. That’s what I thought I did but Google Analytics still didn’t work. Only after hours of blood, sweat and tears did I realize that I had put google-analytics in my _config.yml file echoing the google-analytics.html file name.
Problem solved I figured that maybe I could help other folks and save them some time by updating the code in the Jekyll minima theme google-analytics.html file. I forked. I pulled. I made the change. I added a nice description. I pushed my code up to GitHub. For a few seconds I was so proud of myself seeing my spanking new pull request up there with the other 20+ PR’s. Reading down the list I soon noted that 2 other people had already submitted the same solution. D’oh!
Being as new and inexperienced as I am I’ve historically found the Issues and Pull Requests on GitHub to be too complex for me to follow and understand. I now see that they can include solutions to problems that I’m struggling with. And there’s no need to offer the same solution that someone else already has. It took only 3 minutes for my PR rejection as redundant. All interesting and fun, though.
]]>“Coding is easy. Setup and maintenance are hard.” – Lots of coders everywhere
I’ve got an old app that’s not too complicated that my old anesthesia department has used daily for over 10 years, It’s currently using Rails 6.1.6 and ruby 2.7.2 that Heroku will no longer let me update starting this coming May 1, 2025. So, time to upgrade. I’ve gone through this process twice before. I’ve tried twice on my own before getting hopelessly stuck and having to call in the cavalry, a real coder named Mykl Clason. (It’s pronounced like “Michael.” You can thank his mom for the spelling who knew that it would build character.) He’s very skilled and patient and rescued me both times. This time I’m taking a break from full time work so might have more time and energy to focus on the upgrade. Fingers crossed.
The Rails Guides provides some guidance on Upgrading Ruby on Rails. They suggest several things: don’t upgrade unless you really need to, great test coverage on the original app and then upgrading slowly, ruby first, and then rails, latest patch version of current version and then to the next version. You fix deprecation warnings and failed tests as you go.
That’s excellent advice. But truth be told, I couldn’t keep up with test coverage long ago. For starters, the tests started to take too long to run on my computer. Then I had different code that needed to be run on different days of the week. I’m sure there’s a way but managing and keeping track of time in my test environment and other details broke me back then. Maybe I can make testing work in rails 8.0.1… ? Maybe? I’m going to try.
My approach will be somewhat different taking into account the relative lack of complexity of my app (I hope) and my time. Here’s my basic outline:
Backup and Upgrade the Database
Use heroku pg:copy to create a duplicate of the legacy database. This will also upgrade it to the latest PostgreSQL version on Heroku, leaving the original database untouched.
Download the Updated Database
Capture a backup of the upgraded database and download it locally for development.
Set Up PostgreSQL Locally
Install and configure PostgreSQL on my local machine, then restore the downloaded backup using pg_restore.
Create a Rails 8 App
Generate a new Rails 8.0.1 app with Ruby 3.3.7 and configure it to connect to the restored local database.
Rebuild the User Model
Recreate the user model in the new app, excluding outdated authentication fields while preserving other attributes.
Test Local Database Access
Verify that the app can interact with the legacy database by running simple queries like User.first through the Rails console.
Deploy to Heroku
Push the Rails 8 app to Heroku and connect it to the duplicated, upgraded database.
Expand Models
Recreate the remaining models and ensure proper database interactions both locally and on Heroku.
Implement Testing
Start with basic model tests, introduce validations, and progressively build test coverage for the application.
Recreate the App
Use test-driven development (TDD) to rebuild the application step by step, ensuring reliability and scalability.
As I reflect now, it wouldn’t be the worst thing to do to try to upgrade this app as is to later ruby versions and then rails versions. If I get stuck, I may explore upgrading the existing app incrementally to Rails 7.2 or adding testing coverage to the original app.
This is my initial overall approach but I will document more specific steps and details as I go along in future posts.
“False starts are starts. So just start.” – Ben Unger
You don’t really understand the problem space until you start confronting it.
ChatGPT does have great insights into a lot of the problems I face. But you’ve got to keep an eye on it. It often makes mistakes and gets confused. We’ll see how useful it is for me with this project.
I’m definitely sympathetic to TDD for creating robust programs but for now I figure that I should apply that to a new Rails 8 app and give a new app longer life on Heroku. You can check out the Rails Testing Guide.
There’s a great article by Rémi Mercier about upgrading from Rails 5.2 to Rails 6.0 with details about deprecation warnings, the rails app:update command, reading changelogs, etc. It serves as a cautionary tale about how upgrades can quickly become overwhelming without proper planning and careful incremental work. I didn’t even know what a linter was that he referred to. (For those of you who, like me, didn’t know what a linter is, it’s a tool that checks your code for style issues and potential bugs, which can be incredibly helpful during an upgrade.)
I haven’t added comments yet, but if you’d like to share your thoughts or experiences, feel free to email me. Have you tackled a Rails upgrade or a similar challenge? I’d love to hear your insights. If I hear from someone, I’ll add a comment section to make discussions easier.
]]>You can find an updated list in the Jekyll Docs
I like the idea of buying a theme for a number of reasons. I like the idea of rewarding someone for his or her efforts. Also, if you get what you pay for I might get a better looking theme with better features. There also may be branding advantages to using a theme that fewer people use because of the payment hurdle.
All that said, I’m reluctant to pay for something that I may not use on a long-term basis. If I continue to get value from this blog – and anyone else gets value from it – then I’ll invest more in it. I like to prove the concept on the cheap. I’ll invest once something has traction and staying power.
Ok. So I landed on the Start Bootstrap’s Clean Blog theme. It looks like it will serve my purposes well. There’s still some setting up to do following the instructions at the Clean Blog GitHub Page but spoons gone, brain fried.
I’m not so excited about spending time customizing the styling and just want to record some thoughts and what I’m up to. So I’m back to minima which I think will serve me well at least for now.
]]>Why am I so tired? What did I do today? For starters I spread salt and sand on my driveway and on the sidewalk in front of my house. 4 inches of snow fell overnight out here in metro-Boston. I’ve got a home salt spreaders but after 5 winters it’s on its last legs. I first noticed that its bolts had rusted as I filled it alternatively with sand and salt. Then I struggled to push it around only for it to leave a narrow ribbon of salt and sand. So much for spreading. Only after I had distributed all of the salt and sand emptying the hopper did I notice that the spreading mechanism had broken and that the wheel that ran it had frozen in place. I’ll look at that more closely another day. You’d think that such spreaders would have more corrosion resistance but that likely costs more than folks like me are willing to pay. So I had to spread out all of those ribbons with a broom myself. Not the hardest task in the world. I actually found the sweeping meditative and relaxing. But it was chilly.
My driveway taken care of I headed to Home Depot where I bought a replacement dimmer as well as the tools needed to replace the current one. Retailers no longer sell most incandescent bulbs in the USA. The old dimmer can’t handle the new, low wattage, LED bulbs which flicker in a way that my wife finds maddening.
My first solution involved changing the LED 60W replacements with 40W incandescent bulbs that they still sell. Those specilized bulbs were designed to go in appliances like fridges and stoves. That change solved the flicker problem but also reduced the light by maybe a third. I think I can do better with a new dimmer designed for LED bulbs. Off to Home Depot for me.
My purchase at HD went uneventfully but when I got home I realized that the grey dimmer I had purchased didn’t match the white plate. 2nd act of the day? Returned to Home Depot to swap out the dimmer a bought for a white one. This would be my first return at Home Depot and I worried about lines and hassle by customer service but shouldn’t have. I experienced neither. The exchange was easy as pie.
Everything for that project lined up, I turned my attention to cooking. I roasted some potatoes as well as some eggplants, the latter destined for baba ganoush. At the same time I also simmered the garbonzo beans I had soaked overnight for some scratch hummus. Everything came out delish but the clean up took a lot out of me (and I don’t have a lot in me to begin with.)
Still, I’ve been eager to set up a blog so I spent the last couple of hours getting this bare bones blog up and running using Jekyll and hosted for free on GitHub using Github Pages. More details and instructions on using Jekyll and GitHub Pages together can be found here. Not much to show for my efforts but still – spoons gone, brain fried.
UPDATE: Did about 15 minutes of time on the exercise bike followed by some stretching and felt better. More about exercise later.
UPDATE 2: Woke up this morning (the morning after writing the above post) with a sore throat. I’ve had mild systemic symptoms – sinusitis, myalgias, pharyngitis (sore throat), fatigue, cold intolerance – for about 5 days now and the sore throat is a reminder that I’m still likely fighting something off or still tired from the fight. Fatigue can linger long after other symptoms. So, I’ll pace myself and stay hydrated.