Posted by matijs
26/09/2024 at 16h54
I think a good process is something like this:
- Add the standard library gems to the dependencies so the warnings go away. For gem projects I think it’s fine to put them in the development dependencies because the published gems don’t need these dependencies right now
- Figure out which gems load the standard library gems
- File bug reports for those gems to make them add the standard library gems as dependencies
- Wait for those gems to be updated and then update the dependencies on those gems in my project
- Remove the standard library gems from the dependencies again
To be honest, I think I have only ever gotten as far as point 2.
Tags
maintenance, programming, ruby
no comments
no trackbacks
Posted by matijs
07/04/2022 at 12h01
Remember that blog comes from weblog, and (I believe) originally was supposed to (also) mean a log of interesting stuff one encountered around the web, as opposed to a collection of largish articles about a specific subject. Remember that before Twitter, the small posts were also posted on blogs.
Let’s do some old-school blogging and post small stuff about random subjects, mostly links.
Tags
meta
no comments
no trackbacks
Posted by matijs
11/12/2021 at 09h26
AsciiDoc is nice because a lot
is possible. However, there are a lot of surprising edge cases that make it
less great as an easy to read and write documentation format.
-
Some list markers support nesting, others do not
If you use a dash (-) as a list marker, that works fine until you want to
create nested lists. Then, it turns out you should be using *.
-
Outdenting lists has very weird syntax.
To outdent a list, you have to add a number of empty lines equal to the
number of outdents plus one, followed by an empty line with a +. This is
too specific for a human-readable format.
-
Escaping only works where it is needed.
Wherever an asterisk leads to bolding, you can escape it using a \ to create a literal
asterisk. However, when the use of an asterisk does not lead to bolding, adding the \
will just lead to a literal \ in the output. Predicting where this will
happen is tricky so you have to constantly look at the actual output.
Tags
asciidoc, processing, software, text
no comments
no trackbacks
Posted by matijs
10/10/2020 at 14h32
For a long time, part of my weekend routine has been updating the dependencies of all my open source Ruby projects. I had set up some tooling to automatically run bundle outdated on all my project directories and make a nice report. For good measure, it would also run RuboCop and tell me if any work was needed on that front.
I would then go through the list of needed work, adjust the dependencies (using KeepUp where possible), activate new RuboCop cops, fix new RuboCop offenses, create pull requests, wait for builds to be done and then merge. There actually was a certain satisfaction in keeping things up-to-date, keeping things neat.
A few weeks ago, I’d had enough. The process of keeping things up-to-date was starting to become tedious, and it was keeping me from writing actual new software. Having had good experience at work with Dependabot I decided to automate dependency updates for all my open source repo’s.
After some experimenting I made the following changes to my repositories:
-
I added a separate named RuboCop job as part of each repository’s Travis CI configuration. To do this requires using the jobs key instead of rvm, like so:
jobs:
include:
- rvm: 2.5
- rvm: 2.6
- rvm: 2.7
- rvm: 2.7
name: "RuboCop"
script: bundle exec rubocop
-
I configured GitHub’s native version of Dependabot to create pull requests daily, using a file .github/dependabot.yml in each repository:
version: 2
updates:
- package-ecosystem: bundler
directory: "/"
schedule:
interval: daily
time: "04:23"
open-pull-requests-limit: 10
All this means is that the manual part has been reduced to just checking that the builds are green for the pull requests produced by Dependabot, and potentially any new issues found by newer versions of RuboCop.
no comments
no trackbacks
Posted by matijs
29/03/2020 at 08h38
Actually, problems only get solved because people roll up their sleeves and do shit, and government is the collective coordinating apparatus that helps us know what shit needs to get done and who needs to do it.
Current Affairs, Everything has changed overnight, via @AnnieGal@mastodon.social
no comments
no trackbacks
Posted by matijs
20/03/2020 at 13h08
Automating away your library release process because you find it boring and tedious is the worst thing you can do. People rely on your releases to be meaningful, have meaningful version numbers, and meaningful release notes. Yes, these take time. But your releases are when your users are reminded that you exist. At other times, your library is just quietly doing its thing. Releases are when your users take notice. They want to read your change log, look at the version number to see if they need to pay attention. You’re in the spotlight. This is your performance. Give your releases some love.
Tags
development, software
no comments
no trackbacks
Posted by matijs
31/12/2018 at 15h46
- Your next release should nearly always come from the
master branch.
- When updating your feature branch, prefer
git rebase master over git merge master.
- When merging your feature into
master, prefer merge bubbles over squash merges and fast-forwards.
-
bundle exec rake should run your tests.
- You still should not check in
Gemfile.lock.
- Use RuboCop. Running just
rubocop should do the right thing. If you need a specific version, add it to the Gemfile. In that case, bundle exec rubocop should do the right thing.
Tags
development, opinions, ruby
no comments
no trackbacks
Posted by matijs
20/09/2018 at 09h03
I happened upon
this comment.
But more important, it just doesn’t work sensibly to explain why many people
decline modest bets (e.g. that someone not on the brink of starvation would
decline a 50/50 lose $100 vs gain $110) bet.
You can look at this bet in two ways. The first is the single bet. Then, you
can think about how bad you feel about losing $100, versus how good you feel
about gaining $110.
The second way is as a repeated bet. And I think this is how people do think
about it: If I bet yesterday, why not bet today? Or, I lost yesterday, I need
to bet again today to ‘make up for it’.
Emotions aside, the reason given that the bet is a good one, is that in the
long run the better will come out ahead. But how long is the long run?
Let’s fire up irb. (I’ve reformatted the lines a bit to fit in an article layout.)
>> def bet; rand < 0.5 ? -100 : 110; end
>> count = 0; sum = 0; while sum < 1; count+= 1; sum += bet; end; [count, sum]
=> [81, 90] # Oops!
>> min = 0; count = 0; sum = 0; \
> while sum < 1; count+= 1; sum += bet; min = sum if sum < min; end; \
> [count, min, sum]
=> [35, -530, 70] # OOPS!
Maybe you can spare $100, but can you spare $530? (Not to mention the fact that
many people can’t spare $100.).
Or even $1340, leading to a $50 win after 136 bets?
=> [136, -1340, 50]
What are the chances of a repeated bet ruining you before you gain anything at all?
>> def compound_bet; min = 0; count = 0; sum = 0; \
> while sum < 1; count+= 1; sum += bet; min = sum if sum < min; end; \
> [count, min, sum]; end
>> def killer_bet(threshold); count, min, sum = compound_bet; min < -threshold; end
>> def killer_chance(threshold); 100000.times.select { killer_bet(threshold) }.count / 1000.0; end
>> killer_chance(500) #=> 8.017
>> killer_chance(1000) #=> 3.532
A betting scheme with a 3.5% chance of losing $1000 doesn’t sound so good…
(The commenter goes on to point to an article that actually doesn’t make the
claim that the given debt is a ‘modest debt’, and seems far more interesting
than that.)
Tags
programming
no comments
no trackbacks
Posted by matijs
25/07/2018 at 06h59
I started reading this, and came upon this line:
Many people claim to know how SemVer works, but have never read the specification.
And I thought: Yes! This is exactly the problem. Everyone talks about SemVer, but no-one reads the specification, so the discussions don’t make sense. Finally, someone is going to Make Things Clear!
…
And then I read this:
Note: Stop trying to justify your refactoring with the “public but internal” argument. If the language spec says it’s public, it’s public. Your intentions have nothing to do with it.
What!? This person complains about people not reading the specifications, and then proceeds to contradict the very first article of the SemVer specification? Here it is (highlight mine):
Software using Semantic Versioning MUST declare a public API. This API could be declared in the code itself or exist strictly in documentation. However it is done, it should be precise and comprehensive.
Whether the language spec says it’s public has little to do with it.
Now, there’s a discussion going on on Hacker News about this article, and clearly I’m not the only one bothered by the quote above, but the commenters are focused on whether languages allow you to control what part of your API is exposed, rather than what the SemVer spec actually says.
No-one understands SemVer.
Tags
annoyance, programming, SemVer
no comments
no trackbacks
Posted by matijs
06/06/2018 at 12h47
I used to use Getting Things Gnome (GTG) to keep my TODO list. However, the project seems dead right in the middle of its Gtk+ 3.0 port, so I’ve been looking around for an alternative. After much consideration, I decided on Taskwarrior. I wanted to keep my old tasks and couldn’t find a nice way to export them from GTG, let alone import them into Taskwarrior. So in the end I decided to create my own exporter.
Getting Things Gnome keeps your tasks in some simple XML files in a known location. HappyMapper is ideal for this. I started out using its automatic mapping, but as my understanding of the GTG format deepened, I switched to explicit mapping of a Task’s attributes and elements.
On the other side, Taskwarrior can import simple JSON files that are super easy to create using JSON from the standard library. The script below will output this format to STDOUT. It’s up to you to use task import to process it further.
I implemented this as a spike, so there are no tests, but I like to think the design I ended up with is quite testable. I get annoyed whenever code becomes cluttered, or top-level instance variables start to appear. So I tend to quickly split off classes that have a distinct responsibility. I may yet convert this to a real gem and see how easy it is to bring everything under test.
Finally, before showing the code, I should warn you that it’s probably a good idea to back up your existing Taskwarrior data before playing with this.
Here’s the code:
#!/usr/bin/env ruby
require ’happymapper’
require ’json’
class Task
include HappyMapper
attribute :id, String
attribute :status, String
attribute :tags, String
attribute :uuid, String
element :title, String
element :startdate, String
element :duedate, String
element :modified, DateTime
element :donedate, String
has_many :subtasks, String, tag: ’subtask’
element :content, String
end
class TaskList
def initialize(tasks)
@tasks = tasks
<span class="instance-variable">@tasks_hash</span> = {}
<span class="instance-variable">@tasks</span>.each <span class="keyword">do</span> |task|
<span class="instance-variable">@tasks_hash</span>[task.id] = task
<span class="keyword">end</span>
end
def each_task(&block)
@tasks.each &block
end
def find(task_id)
@tasks_hash[task_id]
end
def root_task(task)
parent = @tasks.find { |it| it.subtasks.include? task.id }
parent && root_task(parent) || task
end
end
class TaskProcessor
def initialize(task_list, handler)
@task_list = task_list
@handler = handler
@processed = {}
end
def process
@processed.clear
@task_list.each_task do |task|
next if @processed[task.id]
root = @task_list.root_task(task)
process_task root
end
<span class="instance-variable">@task_list</span>.each_task <span class="keyword">do</span> |task|
raise <span class="string"><span class="delimiter">"</span><span class="content">Task </span><span class="inline"><span class="inline-delimiter">#{</span>task.id<span class="inline-delimiter">}</span></span><span class="content"> not processed</span><span class="delimiter">"</span></span> <span class="keyword">unless</span> <span class="instance-variable">@processed</span>[task.id]
<span class="keyword">end</span>
end
def self.process(tasks, handler)
new(tasks, handler).process
end
private
def process_task(task, level = 0)
@handler.handle(task, level)
@processed[task.id] = true
process_subtasks task.subtasks, level + 1
end
def process_subtasks(subtask_ids, level)
subtask_ids.each do |task_id|
raise "Task #{task_id} already processed" if @processed[task_id]
task = @task_list.find(task_id)
process_task task, level
end
end
end
class TaskWarriorExporter
def initialize(task_list)
@task_list = task_list
end
def handle(task, level)
status = case task.status
when ’Dismiss’
’deleted’
when ’Done’
’completed’
when ’Active’
’pending’
else
raise "Unknown: #{task.status}"
end
data = {
<span class="key">description</span>: task.title,
<span class="key">status</span>: status,
<span class="key">uuid</span>: task.uuid,
}
<span class="keyword">if</span> task.duedate
<span class="keyword">if</span> task.duedate == <span class="string"><span class="delimiter">'</span><span class="content">soon</span><span class="delimiter">'</span></span>
data[<span class="symbol">:priority</span>] = <span class="string"><span class="delimiter">'</span><span class="content">H</span><span class="delimiter">'</span></span>
<span class="keyword">else</span>
data[<span class="symbol">:due</span>] = task.duedate
<span class="keyword">end</span>
<span class="keyword">end</span>
data[<span class="symbol">:end</span>] = task.donedate <span class="keyword">if</span> task.donedate
data[<span class="symbol">:scheduled</span>] = task.startdate <span class="keyword">if</span> task.startdate
entry = guess_entry(task)
data[<span class="symbol">:entry</span>] = entry
subtask_uuids = task.subtasks.map <span class="keyword">do</span> |subtask_id|
<span class="instance-variable">@task_list</span>.find(subtask_id).uuid
<span class="keyword">end</span>
<span class="keyword">if</span> subtask_uuids.any?
data[<span class="symbol">:depends</span>] = subtask_uuids.join(<span class="string"><span class="delimiter">'</span><span class="content">,</span><span class="delimiter">'</span></span>)
<span class="keyword">end</span>
data[<span class="symbol">:tags</span>] = task.tags <span class="keyword">unless</span> task.tags.empty?
<span class="keyword">if</span> task.content
data[<span class="symbol">:annotations</span>] = [ { <span class="key">entry</span>: entry, <span class="key">description</span>: task.content } ]
<span class="keyword">end</span>
puts data.to_json
end
private
def guess_entry(task)
dates = [task.duedate, task.donedate, task.startdate].compact.
reject { |it| %w(someday soon).include? it }.
sort
dates.first || task.modified.to_s
end
end
projects_file = File.expand_path ’~/.local/share/gtg/projects.xml’
projects = HappyMapper.parse File.read projects_file
tasks_file = projects.backend.path
tasks = Task.parse File.read tasks_file
task_list = TaskList.new tasks
TaskProcessor.process(task_list, TaskWarriorExporter.new(task_list))
Tags
code, getting, gnome, happymapper, things
1 comment
no trackbacks