Tridactyls, Python For Kids, and Real-Time Flowcharts
Shmig is a database migration tool written in BASH consisting of just one file —
last commit: June 9, 2019, first commit: Oct 1, 2013
Wireflow is an open-source flowchart real-time collaboration tool.
last commit: July 11, 2020, first commit: Nov 19, 2017
Python For Kids is a comprehensive and free online Python development course for kids utilizing micro-controllers.
last commit: 2 days ago, first commit: Sep 16, 2020
In a follow up from last week’s doslinux link, here’s another funky one. Tridactyl allows you to replace Firefox's default control mechanism with one modeled after Vim’s.
last commit: 16 hours ago, first commit: Feb 9, 2017
Actionsflow is a free IFTTT/Zapier alternative for developers to automate workflows based on Github actions. This one is probably my favorite of the week. I’m really liking the ecosystem of software that’s cropping up around GitHub.
last commit: 1 hour ago, first commit: Sep 29, 2020
Argbash is a bash code generator for command-line arguments.
last commit: 10 days ago, first commit: Aug 13, 2015
Vision Blender is a computer vision add-on for Blender.
last commit: October 2, 2020, first commit: Dec 3, 2019
igel is a CLI tool to run machine learning without writing code.
last commit: 7 hours ago, first commit: Aug 27, 2020
Interview With Dr. Oliver Blanthorn of Tridactyl
What is your background?
I turned to computers - mostly videogames - from a young age. Growing up on the Isle of Wight in the UK, there wasn't a great deal else to do with my free time other than walking. It is an amazing place: I caught a lovely WWII-era train to school every day (in 2007!), and I could see hovercraft crossing the Solent (the stretch of water separating it from the UK mainland) from the school fields.
The first taste of programming I got was writing a first person cockpit script for Multi Theft Auto, a GTA: San Andreas mod. I've had perhaps surprisingly little formal training in programming - my undergraduate degree was in Physics where the attitude was "programming is easy - you'll pick it up when you need to". I then did a PhD in Computer Science where the attitude was "of course you have been taught how to program". This is probably why Tridactyl has so many bugs ; )
C++ was my language of choice at undergraduate level, but once I got to PhD level I wanted to be able to experiment more easily. I started using MATLAB more, and Python with Jupyter notebooks. Those languages are very slow if you are writing your own routines. The impossibility of multithreading in Python was the final straw - many problems in science are embarrassingly parallel because you want repeats, so multithreading is really useful. I ended up finding Julia which I used for most of my PhD and is still, by far, my favourite language. It's fast, concise, and has pretty good multithreading.
Why was Tridactyl started?
At the end of 2016, Mozilla announced that towards the end of 2017, all current Firefox extensions would cease working unless they were rewritten to use a completely different API.
I was a keen user of an extension called Vimperator (closely related to another extension called Pentadactyl). I kept an eye on the GitHub thread talking about porting Vimperator to the new APIs, really hoping that someone would step up to port it. It became clearer and clearer that no-one was going to port it. I roped a friend, Colin Caine, into looking in to it with me and we decided that we should just try to recreate Vimperator from scratch using the new WebExtension API. The name Tridactyl came from two jokes: it's like Pentadactyl but a bit worse, and it's just something we were "Tri"-ing to do.
So essentially we started it because something we liked was going to go away. We really didn't want it to go away and really quite reluctantly stepped in once it looked like there wasn't an alternative.
Are there any overarching goals of Tridactyl that drive design or implementation?
We're unashamedly only for expert users who have the time and inclination to learn a new tool and shape it to suit them well.
What tradeoffs have been made in Tridactyl as a consequence of these goals?
Tridactyl is unfriendly to new users. As soon as they install Tridactyl they're greeted with a huge wall of text telling them to follow our tutorial, which is terribly unfashionable these days. I'm struggling to think of any other piece of modern software that is so presumptuous - perhaps DCS, the combat flight simulator? I think last time I checked our manual spanned over 200 A4 pages. A printed version of "Tridactyl: A reference guide" has long been a joke monetisation strategy between the developers.
I think there's also a kind of implicit contract with our users where they understand that the darker corners of Tridactyl - the features which are used less often - aren't very well tested and might break or be broken, and that if they want it fixed they should tell us about it. And usually our reaction when they tell us is to give them a short sketch of how to fix it in a PR. I'd say about 10% of the time we actually do get a PR, which is a pretty amazingly high number.
What is the most challenging problem that’s been solved in Tridactyl so far?
I'm not sure anything we've done has been especially technically interesting or technically challenging - I'm a firm believer in keeping code as unclever as possible. I like to joke that it comes naturally to me but in truth it requires a fair bit of discipline.
By far the most challenging non-technical issue we've had is that in 2019, Mozilla took issue with some code we'd written - and because Mozilla decides which extensions can run in Firefox, even ones distributed outside of their store, that was a big deal. They wanted us to run some more code on users' machines to revert the things that our code _might_ have done. I really thought (and still think) that running code without our users' consent is a bad thing to do. Mozilla delisted Tridactyl from their addons store (which to my immense frustration meant we couldn't provide bug or security fixes to our users) and said they would reach in and remove Tridactyl from all of our users' machines if we didn't comply.
In the end, a clear majority of Tridactyl users who we asked were OK with us running this code if the alternative meant that they wouldn't be able to use Tridactyl. So we eventually just did what Mozilla asked us to.
It served as a wake-up call for us: Tridactyl is now packaged for Arch Linux in such a way that Mozilla doesn't get a say in whether it should or shouldn't be allowed to run in Firefox. I don't like people telling me what I can or cannot do with my computer so I prefer this model.
How is Tridactyl currently monetized?
We get donations via GitHub sponsors (who are doubling donations until the end of November - Microsoft have been unbelievably generous), PayPal and Patreon. It's currently enough money that I can justify working on Tridactyl around one day a week without feeling too guilty about being underpaid.
I've been toying with porting Tridactyl to Chrome and charging a fairly high yearly licence fee for updates. It feels fair to me - it would be open source so anyone who wanted to build it themselves could do; I don't really want to port it to Chrome as it would be a lot of work and I don't use Chrome; and philosophically I'm concerned about Chrome's massive market share, so I don't want to encourage people to use it. It could also be a challenge to get Tridactyl accepted onto the Chrome web store as their reviewers are quite famous for being obtuse. A lot of people who use free software expect it to be free-as-in-beer so we might get some backlash, so we need to weigh that up too.
What is the best way for a new developer to contribute to Tridactyl?
Honestly: regularly give us some money! The more money we have, the more time we can afford to spend on Tridactyl.
If you'd rather donate time, https://github.com/tridactyl/tridactyl/blob/master/contributing.md has some pointers on where to get started.
Where do you see Tridactyl heading next?
We have almost 500 open issues. I'd like to do some unsexy work fixing bugs and closing them.
Where do you see software development in general heading next?
I think people are going to take dependencies more seriously. Julia and Rust now both have excellent package managers that allow you to easily keep your dependencies up to date. I hope that most other languages follow suit.
In terms of scientific computing, I think people will start to move away from notebooks (like Jupyter) towards solutions that are more reproducible like Observable and Pluto.jl. Traditional notebooks are fantastic for exploration but they make it very easy to get lost.
Where do you see open source heading next?
I don't know. Funding is still a difficult question. Tridactyl has it relatively easy here because we directly have wealthy end users who understand that developers need to eat and it just so happens that we can remind our users of this in a fairly prominent place without it being too annoying (I hope!).
I'm not sure that the proliferation of anti-cloud licences, in the hope that Amazon will give people who develop software that is used upstream of end users some money, is a good solution. I suspect the easiest answer is that firms should employ people who work on important projects directly. Another aspect is that a fair amount of open source work is indirectly government funded - researchers at universities often quietly work on software. I think we would get more and better software if that work was more formally encouraged and recognised.
Interview With Owen Young of Actionsflow
What is your background?
My major in university was computer science and I have been a graduate for 4 years. In the first three years, I did front-end development in a large technology company, but I left my job last year to become a freelancer. Since high school, I have been interested in making websites. I tried to build some PHP websites by copying and pasting the source code. When I was in college, I learned nodejs on the Internet and made some campus websites and services. Until now, js is my most commonly used language, but now I prefer to use typescript for static types. I am very interested in the jamstack. Gatsbyjs is a great tool for jamstack. I also love to use React for front-end jobs.
Why did you decide to leave the large technology company?
The reason for leaving my job is because the work content of each project is similar, a little boring, and there was more overtime. I wanted to be more free, so I gave myself 3 years to do something I want to do.
How do you like freelancing so far?
It's more fun, and free. I have enough time to build what I want to. I'm still developing a blog-related tool. I made a campus community app for college students before, but it didn't go online finally. At present, I basically have no income. I live on the money I made in the big company from before. Despite this, I still don't regret my decision.
Why was Actionsflow started?
I’m a workflow lover. I hope that workflows can make my life convenient and orderly. I hope the tool is simple and extensible. IFTTT is easy to use, but it can’t meet my personalized needs. Zapier is nice, but it’s not cheap. The other self hosted open source alternatives like n8n and huggin are also awesome, but self hosted deployment is still a bit difficult. Because they are based on GUI, if you want to create your own triggers and actions, it is a bit complicated. So I think the best experience for developers is probably to configure the workflow in a descriptive language. Github defines a syntax specification for configuring an actions workflow. It is simple, extensible, and a large number of developers are using actions. I think it’s a good idea to use the actions syntax to configure the developer’s personal workflow rather than a GUI.
Are there any overarching goals of Actionsflow that drive design or implementation?
I’d love to say the goal of Actionsflow is simplicity and extensibility.
What trade-offs have been made in Actionsflow as a consequence of these goals?
The design of a webhook url is one tradeoff. For supporting the webhook feature, I designed a forwarding service, it’s format is:
I have to say that it‘s a bit annoying for users to manually stitch such a long url. But, there is no more convenient way, we indeed need the information in the url to forward it correctly.
What is the most challenging problem that’s been solved in Actionsflow so far?
I have to say that technology is not the challenge of Actionsflow, it’s not hard to build Actionsflow. The most challenging problem so far is the running time of Actionsflow. I wanted Actionsflow to run as quickly as possible, so I took advantage of all available caches, and tried not to install huge node_modules to perform tasks, but to use the built-in actionsflow.
Is Actionsflow intended to eventually be monetized?
No, the goal of Actionsflow is free and open-source, and it is based on Github Actions, I don’t intend to monetize.
What is the best way for a new developer to contribute to Actionsflow?
Both documentation and code are welcomed. I’d love to see users share their triggers and workflows to the Actionsflow community.
Actionsflow also has a contributing guide: https://github.com/actionsflow/actionsflow/blob/main/docs/contributing.md
Where do you see Actionsflow heading next?
I want to provide more and more triggers, actions for workflows, and am considering supporting a self hosted version for Actionsflow.
Where do you see software development in general heading next?
For individual developers and small companies, I think it's serverless. Serverless architectures offer greater scalability, more flexibility, and quicker time to release, all at a reduced cost. Like the Actionsflow web hook forward service, I deployed it to Cloudflare’s workers. It’s so easy to deploy it, and they provide 100000 free requests per day.
Where do you see open source heading next?
I think the income of the author with open source will be a more pressing problem. Like n8n, an alternative to Actionsflow, they have updated their licence to https://faircode.io/, and I see more and more notable reminders for sponsorship. So, I think the income will be an important problem for open source. The authors need a better solution.
Like what you saw here? Why not share it?
Or, better yet, share Console!
Also, don’t forget to subscribe to get a list of new open source projects curated by an Amazon software engineer directly in your email every week.