TL;DR – Create a github issue for each sketch. Link to that from the sketch. People can comment on the issue. Brilliantly simple. I made the system a bit simpler than described in that article. I’m not pulling in the comments to the sketch page, just linking to it.
I actually had set up Disqus to open up in a overlay div. It worked fine, but I wasn’t super happy with it. It was like, the site is here, the content is here, the source code is here, and the comments are … way over here on this other unrelated site.
With the github solution, the site is here, the content is here, the source code is here and right along in the same package are the comments.
It’s a bit more work for me. I have to create the sketch, then create the issue, add the sketch url to the issue, and add the issue url to the sketch. The template I have for sketches handles most of the boilerplate because everything is indexed to the sketch date in the format YYMMDD. But the issue url will be sequentially numbered, so the issue will need to be created and then the url added to the sketch html. Not a big deal. But the Disqus method was 100% automated.
Anyway, hopefully this will allow a decent way for people to comment, discuss, ask questions, etc.
One of the key aspects of the lab has always been that it’s open source. The code is not particularly written in a manner conducive to education. It’s often the result of me hacking around until I find something that looks good. At that point, it’s done. No heavy duty refactoring, cleaning up, commenting. You get what is there, and if you can figure out what I’m doing, great. If not, feel free to ask, and maybe I’ll try to explain. Maybe not. I might have forgotten what the code does myself.
Anyway. I was looking at the flow. You see something in the lab you like, you have to take note of its number, somehow navigate to the github site, go into the dailies directory and find the js file with that number. Or, maybe you’ve cloned the repo. You can pull any updates and navigate to that spot on your file system.
But hey, that source file just lives at a standard url right? Why not give the nice viewers a link to click on? So there you go. Right up in the description box, there’s a “source” link that’ll take you right to where the code for that particular experiment lives.
I’m also trying to figure out a way to enable comments or discussions. Ideas I’ve had so far:
1. Disqus. I got it working easily enough, but the UI is not going to work out. I want each experiment to be full screen with only the home link and info box. I could make an additional link or button that opens up the Disqus UI in some kind of popup, but I wasn’t really liking where that was going.
2. A forum. That’s a possibility, but kind of a heavyweight one. I’ve run forums before. Not sure I really want to get back into that. And forcing people to make forum accounts and profiles, etc. Not into it.
3. Github wiki. I’m just not familiar with that. Could work out. One wiki page per experiment. Open to anyone editing. Open to abuse, I guess. Anyone have any experience with this?
Any other suggestions? I think a github-based solution would be great. Surprisingly there’s no straight up comment feature in github that I can see. There are issues and pull requests, sure. But is there something where you can just comment on a file or folder?
I just ticked off another feature on the BIT-101 Lab list. A visual index.
Back in the old Flash Lab the only way to find a specific experiment you wanted to look at again was to click through, one by one, trying to remember the approximate date and targeting items around that. I wanted to avoid that pain. The first thing I did was to add tags and the ability to search by tags. This should help a lot. But I think this visual index will help even more. You can just scroll until you see something that looks like the thing you want to check out, and click away. It will also be good for discovery, I think.
At any rate, I think it looks pretty cool. I test-populated it with about 15 future experiments and it really starts to look great when there are lots of images in the list. I can’t wait to see it grow.
This weekend I was in a book store (remember those) and ran across this book – Beautiful Geometry.
A few minutes of looking at it, and I was on my way to the register to buy it.
Each chapter takes on a specific, interesting mathematical / geometric principle and takes a couple of pages to explore it. There’s a bit of history, some formulas, some images and diagrams and some practical uses.
The very first chapter, on Thales’ Theorem gave me an immediate realization on how I could solve a problem from Euclidea. Actually I had solved that problem, but had no clue how. Seeing and understanding Thales’ Theorem gave me instant understanding of how to solve the problem. I opened the app and solved it without a hitch.
I’ve gone through a few other chapters. Great stuff. I’ve worked a couple into future experiments in the BIT-101 Lab. I’m sure this book will fuel several more pieces there.
Note, this is NOT a coding book. There isn’t even really more than a passing reference to computers here. But it explains the concepts and formulas well, so you shouldn’t have much trouble applying the concepts to code.
I’m a math nerd. I’ve actually never had any real professional math training. I just like studying mathematical concepts and figuring out formulas. In particular, I like any math that can be graphically visualized. If it can be animated, all the better. Computers and math and graphics and animation – that’s the stuff right there. If you’re in the UK, :s/math/maths/g
Recently I ran across an Android app called Euclidea. And soon discovered that while naturally there is an iOS app, there is also a web site that has all the same content.
Basically, there are 120 problems, or levels. In each level you need to construct some geometric form, place a point or line or form an angle that fulfills some criteria. The initial tools you have are a straight edge and a compass. As you figure out different techniques, those get added as shortcut tools. For example, using only a compass and a straight edge, you can form a line that bisects a given line segment. When you figure that out, you are given the perpendicular bisector tool that does that in a single step.
While simply solving a given level is OK, there are also goals to meet, such as solving it in a minimum number of steps. It gets a bit complex, but each problem has an L-score and an E-score. E is the number of Euclidean constructions. This would be a line drawn with the straight edge or a circle drawn with the compass. L is the number of “lines” drawn using any of the complex tools you discover. For example, using the perpendicular bisector tool would count as one L as you use that tool one time. But it counts as three Es, as it takes drawing two circles and a line.
Some of the problems – even on the higher levels – are fairly easy and straightforward. A few had me completely stumped and I had to resort to searching for an answer. Most of them I can solve, often within the L goal, but usually have a much harder time with the E goal. There’s even an active Quora community dedicated to the best solutions to the various problems. Fun stuff.
The Android app is free, but you have to solve a certain number of problems on lower levels with the correct L and E scores to unlock later levels. Or just pay to unlock everything. I paid.
Long time readers of this blog may recall what existed here before “blogging” was a thing – the BIT-101 Lab.
Back in the late 90′s / early 2000′s there were a bunch of people running Flash “experiment” sites. Basically, each day they would post some kind of visual, animated and/or interactive Flash piece, often open sourced. Josh Davis’s Praystation, Jared Tarbell’s Levitated, Robert Hodgin’s Flight 404 were some of my favorites. In August 2001 I decided to blatantly copy them… I mean… jump on that bandwagon. My site at the time was called “KP Web Design”. Sigh. I started doing some experiments and decided I needed a better domain, so I came up with bit-101 and moved all the experimental stuff over there. It went live on September 11, 2001. Yes, THAT September 11th. So nobody really noticed it for a while. But over the next four years I posted just shy of 700 open source Flash experiments that explored all kinds of neat techniques. The site won an award (FlashForward 2003 – Best Experimental Site) and really pretty much launched my career.
In 2003 I started this blog. And by 2005 the lab was retired. I blogged heavily for several years, but in the last few years, not so much. I’ve had other interesting projects over the years, but nothing was quite as exciting as those lab days. Recently Zach Lieberman posted about his 2016 project of posting a sketch each day (sketch/experiment, same concept). It inspired me to get back to basics.
I have template files and a script to create a new daily sketch / experiment based on the templates. This goes into a dev folder where I can work on it. When I’m ready to release it, I move it to the dailies folder, update the index.json file, add, commit and push. This updates the source and publishes the new file to the site. Because the site IS the source… etc.
One thing you’ll see in there is the use of a couple of libraries, bitlib and QuickSettings. You might be familiar with the latter. But the bitlib library is something I’ve been working on quietly for a while. It’s really just for my own use. It’s not something that I want to promote and convince other people to use and then have to wind up supporting. It’s just a compilation of the functions that I wind up using over and over. It’ll grow and change over time. Feel free to use it as much as you want – at your own risk. I make no claims for it’s production-readiness.
The site code is pretty rough. Again, I banged it all out over the last week in my spare time. But I’m quite proud of the calendar UI I created from scratch. And the tag searching and indexing. It’s even responsive and stuff. I have plans to take a screen shot of each experiment and present a visual index as well. And I’m thinking about ways to automate that index / tag generation portion. But it all seems pretty good right now for starters.
Anyway, I’m pretty excited about this. I know that on day one, there’s not a whole lot to be excited about from your end, but hopefully as the calendar fills up, it will become a fun place to visit and play with and learn from.
I’m really happy with the changes in this version. I use QuickSettings myself all the time, so most of the changes stem very much from personal experience – seeing my own pain points and addressing them. The key motivation for changes in this release was making the library easier to use.
One of the annoyances I noticed was in getting values from a panel – you had to know what kind of control you were querying and use the correct get method, i.e. getRangeValue(title) or getColor(title) or getText(title). And the same for setting values. Since the panel knows what kind of control it is setting or getting via the title, there was no reason to force the user to specify it. So all that is gone. All controls can be set or get with setValue(title, value) and getValue(title).
Since all controls now used the same interface for getting and setting values, this allowed me to vastly simplify the getValuesAsJSON method, returning an object or JSON string of all the values in a panel. It also allowed me to easily create a corresponding setValuesFromJSON method. Since both of these methods utilize the same JSON format, you can grab the values at one point and reset the panel using that same object. The Reset Demo (source) shows one example of how to use that. You could also use this technique to create multiple presets for panels.
Having a single format to get and set all panel values opened up a solution for another situation that annoyed me. In working on some experimental piece, I’d create a panel, and adjust various values in it, and then need to change the code. When I re-ran the application, the panel was of course back to its original state. And I’d have to go adjust the values again. The solution is saveInLocalStorage(name). When you call this method on a panel, it immediately looks for an item in localStorage with the given name. If it finds one, it uses setValuesFromJSON to reset the panel to the values found there. It then listens for any changes that occur to any values in the panel and immediately saves them to local storage under the same name. This means that the next time you start the app, the panel will initialize with the same values it ended with in the last session. Check the Local Storage Demo (source) to see this in actions.
I’ve also been paying a lot of attention to the size of the library, trying to keep it as small as possible. This includes removing any code that is not vital to the project. So there were some removals in 3.0:
I noticed a while ago that setInfo and setHTML were almost exact duplicate methods. So I just made setInfo into an alias for setHTML. In version 3.0, setInfo is gone altogether.
Finally, I removed the whole snap-to-grid functionality. I found, personally, that I wasn’t moving panels around that often anyway, and when I did, I didn’t really care if they snapped to any kind of grid. It was a neat feature, but not essential.
Between the simplification resulting from the new get/set methods and the removal of the items mentioned, I was able to cut about 4k off the library size, making the minimized library about 20.5k.
Of course, these changes may break some existing apps. Hopefully not too badly. And I think the added simplicity and functionality is worth it.
One thing not as visible is that I’ve also started unit testing the library. This was long overdue. When I started changing the set/get methods, I saw that I was going to need to do a ton of manual testing on each and every control to make sure that I wasn’t breaking anything. Forget that. It’s all automated now. All the set and get methods are thoroughly and automatically tested now. In addition to making sure that the new functionality worked correctly, this testing also unearthed several pre-existing issues that I probably never would have noticed. Those are now fixed too. All the tests are checked into the repo, so if anyone wants to add additional tests in there, I’ll happily pull them in. I mainly concentrated on the value functions, but there’s a lot more in the library that needs to be added to testing.
The first one was released there, and it turns out that this arrangement is not going to work out the way I hoped it would. Let me say at the outset that there is no problem between myself and the company. I’ll continue to produce egghead.io-specific videos for them. But I thought that moving the Coding Math stuff over there would be a simple matter of uploading it and publishing it there. And that’s not the case. Naturally, egghead.io has a brand and certain standards and style guidelines necessary for keeping consistency when dealing with so many different instructors. Actually, it’s not so much of a “style” as a stripped-down, “just the facts” concept, which is great. I wholeheartedly agree with that concept. But the Coding Math videos, as-is, break too many rules and would have to undergo surgery on a video-by-video basis in order to fit in to that universe. Also note that egghead.io was not refusing to publish them. They were very accommodating, even offering help in terms of manpower to do that editing.
In the end though, after a night and day of soul-searching, I have decided to keep the Coding Math “brand”, such as it is, independent. This decision makes absolutely no sense financially. I’m walking away from lots of easy money. But Coding Math has always been more of a labor of love than a money-making operation. So for better or worse, the channel will now live on as-is, YouTube only, Patreon supported, assuming not too many of you have jumped ship.
On a related note, I would like to do more in the sphere of teaching. I’d like to gauge the interest in a live “Coding Math” or “Making Things Move” course. A one- or two-day, in-person course held somewhere in the Boston area. If successful, maybe occasional road shows. Or possibly a live on-line course, or (though I despise the term) “webinar”. Are these things that people would be interested in? What would such a course be worth to you? If anyone has any experience, resources or contacts in any of those areas, let me know.
I’m happy to announce that Coding Math videos will now be available on egghead.io.
Since I started making videos, it has been a great source of joy for me. I love teaching, whether it is writing, speaking or making videos. It’s very fulfilling to spend time learning a subject and then be able to distill that subject down into simple enough terms that others can understand it and actually USE it. And the tons of positive comments I have received on the videos have totally defied my previous views of what YouTube comment sections were supposed to look like. I don’t answer all of them, but I do read every single one and it’s always a nice pick-me-up to get one of your great comments.
At the same time, making videos takes a lot of time and energy. I usually think over the script in my head – often on long walks with my dog – for a couple of days. Then I try to come up with good, simple code examples. This is key, in my opinion. It’s where a lot of other educators and authors fall down, I think. The example needs to be realistic enough that you can see how you could use that in a real project. But at the same time, you don’t want a full fledged application with all kinds of other junk that’s obscuring the one principle you are trying to teach. I remember seeing a tutorial for parsing XML some years ago, that went on for ages on pixel-level details on how to build the UI for displaying the XML. Utterly irrelevant. The code examples usually take me from one to a few hours. Then I start writing the script explaining the concepts and going through the code. That’s generally a couple of hours minimum. Screencasting all of the code and any diagramming, gathering other graphics and screenshots, etc. is another hour or two. Recording the audio is pretty quick. I do it in one take and just back up and start talking again if I make a mistake. Editing the audio for a 10-15 minute video takes around an hour. Then, putting it all together – making all the audio match up to all the video, all the cuts and transitions, etc. can be anywhere from 2-4 hours. So we’re usually talking a minimum of around 8 hours for the full production of a 10 minute video. Maybe twice that for a more complex one.
So, while the praise and thanks are nice, it would also be good to get remunerated for that time somewhat. My approach to this so far has been through my Patreon campaign. Many of you have contributed to Patreon, and I am grateful beyond words at the fact that you have gone ahead and given money that you didn’t have to give to support my efforts. Thank you all who have donated. Seriously.
As it stands, I make about $90 to $100 from Patreon each time I release a Coding Math video. Given the time I put into them, that’s somewhere close to minimum wage. If, a week AFTER I release a video, that video goes viral and 100,000 people watch it, I will get… $0. If that video continues to get thousands of hits per week for the next 5 years, I will get … $0. It’s not that I don’t appreciate the Patreon contributions, but it’s really not the best system for this type of content.
There’s also Youtube ad revenue. This does reflect ongoing views, but with almost 15,000 subscribers, this results in an average of about $20 a month. Not really worth discussing.
I’ve also been making videos for egghead.io. I’ve kept these quite separate. So far they’ve been series on specific subjects. The egghead.io platform is great – both for customers and instructors. If you are a web development professional, it’s possibly the best resource to stay up to date on current technologies. For something like $199 a year, you get an amazing wealth of ongoing, current, as well as archived material. egghead.io also has a library of free videos. As an egghead.io instructor, I continue to earn revenue on older videos, as long as they are still being watched. And unlike YouTube, it’s actually a significant amount.
So it’s been a struggle for me on which to concentrate on. I love creating the Coding Math series and letting people learn for free, but also like doing the egghead.io specific videos that earn me money. Fortunately, there is a way to combine both.
Coding Math videos will now be published first on egghead.io. The will be released for free, and will remain free for anyone to watch, any time, ever. Just like on YouTube. But I’m sure you’ll rest much easier knowing that I’m being well compensated!
And as I said earlier, if you like the free stuff you see on egghead.io, I highly recommend signing up. Maybe get your company to get a subscription.
Well, this post has been some time in the making. As I mentioned a week or so ago, I’m back on Linux full time on my main personal machine. That machine, by the way, is a 3 year old Lenovo Yoga 2 Pro. Probably my favorite computer ever so far. The only thing that is showing its age is the battery. It was never that great to begin with, now, you can practically watch it drop by the minute. But since I mainly use it at home, it’s not been a huge issue.
Anyway, I initially fired up Ubuntu 16.04 on it. Because that’s like the default. Ubuntu is great. You literally just put a disk in the drive, or a USB drive in the slot, boot into it, click a few buttons, enter your name, password, time zone, and about 10 minutes later, you’re up and running. Everything just works. The only thing I had to tweak was my touchpad, which involved writing a config file with the various settings. And tweaking that config file until it felt just right. Sounds like a pain, but on Windows I also had to tweak it. And to do that I had to go into the device manager and get the device id and then go into the registry editor and find the right key, then find the right option to make it do what I wanted. All told, the text-based config file is far easier.
One thing about running Gnu/Linux is choice. You can change just about anything. I’m not a big fan of the Unity interface in Ubuntu, so I swapped that out for Gnome. This involves installing the Gnome desktop and choosing that at login. But it bugged me that all that Unity code was still there under the hood, taking up space, and doing God knows what. So I wiped the whole install and installed UbuntuGnome. This is Ubuntu, minus Unity, plus Gnome. On the surface, not at all different than what I had. But I felt better about it.
OK, all would seem to be good. Then I started doing videos. First problem. I found that while doing screen casting, the recordings would have all kinds of tearing and glitching. This was indicated to be an issue with Gnome 3. OK. Dropped into the earlier version of Gnome which installs along with 3. Same problem. OK, maybe it’s just a Gnome thing. I liked Gnome, but if I can’t screencast with it, it’s no good to me.
So, wiped things again and installed Mint. Mint is a beautiful OS. It’s an Ubuntu derivative, but has it’s own desktop environment called Cinnamon. It used to be my OS of choice and after I installed it, I remembered why. It’s so nice. Even better than Gnome.
Unfortunately, I had the same issues with tearing while screencasting. After some more research, it has to do with “compositing”. When you have a window manager that can show different windows on top of each other, behind each other, over a desktop with other things on the desktop, maybe certain elements have shadows and transparency, the act of arranging all of these elements correctly is compositing. And such a window manager is known as a compositing window manager. Most window managers are compositing. Mac, Windows, Ubuntu, Mint. It’s what you are used to. But this can cause a problem with screencasting in some cases. I don’t know the details, but I guess when the screen recorder is capturing frames, the timing can be off and it starts capturing things at the wrong level, maybe capturing things as they are in the middle of being drawn. There are probably solutions to this, but learning about this brought up the question, “what is a ‘non-compositing’ window manager?”
It turns out there are a few popular non-compositing window managers on Linux. Most of these are called “tiling window managers”. A couple of the most popular ones are xmonad and i3wm (or just i3).
The way these work is when you create your first window, it is automatically sized to fill your entire screen. When you create another window, the two windows are tiled, so one fills one half of the screen and the other fills the other half. More windows split up the screen further, either vertically or horizontally. There’s no wasted space. There’s no overlap. Once you have anything running, there’s no desktop. Only your apps, filling virtually every pixel of the screen. Tiling window managers are usually very keyboard based, with shortcuts for moving between windows, moving windows around, switching between multiple workspaces, opening and closing programs, etc. This is a good demo for what this looks like in i3:
Now I’ll admit. This sounds HORRIBLE. It sounds like going back to the 90′s and Windows 1.0 or something. But I’d heard glowing reports of people using these things. So I tried it out. At first, yes, awkward. Then I learned a few tricks. Got used to the workflow a bit. And literally started smiling. I tried both xmonad and i3. I went with i3 because it uses a text-based config file, whereas for xmonad you have to configure it with a Haskell script. And I don’t know the first thing about Haskell.
Here’s an example of my current desktop running on i3:
Good news: screencasting was flawless. And the more I used i3, the more I absolutely love it.
Bad news: i3 is tiny and lightweight. Which made me unhappy again about all the crud that was installed under the hood to support Unity or Gnome or Cinnamon, etc. I really just wanted a distro that only had the bare minimum stuff in it to allow me to boot up and launch i3.
After searching around some, I discovered Arch Linux. OK, I’d heard of Arch before. It’s one of the main distros out there. What I didn’t know is how minimal it is. For comparison, when you boot up the Ubuntu installation media (CD or USB), this is what you get:
A nice pretty installer with nice, pretty, big buttons to guide you through the steps. It does most of the work for you, requiring just a bit of input from you.
In contrast, when you boot up the Arch installation media, here’s what you get:
I thought it failed at first. But no, you get a command prompt. And no instructions on what to do. It’s ALL up to you. And it’s pretty much all command line. You start by manually partitioning your disk(s), making file systems on them, mounting them to the proper spots, then installing the system to the right place on the right partitions, setting up various config files, installing the boot loader, etc.
If you do everything right, you reboot, Arch launches, and you get… another command line. The default install adds almost nothing beyond what the system needs to boot. Probably the first thing you need to do when you get it running is set up your network – wifi drivers, etc. Then you can start installing other stuff off the net.
To run i3, you need something more than a console. You need a graphical UI. This usually means installing Xorg and configuring that. Then you need to install the programs that will run there. You don’t even get a default terminal emulator. You have to choose one and install it. You want a web browser? Choose one and install it.
If this sounds horrible and tedious to you, I understand. It’s not for everyone. For me, it made me very happy. I know almost every piece of software that’s installed on my system now. Because I installed every one. I know exactly how the boot loader and graphics system and wifi devices are configured. Because I configured them.
The Arch Wiki is an amazing repository of knowledge. And combined with the Arch Forums, there’s no problem that can’t be solved. My Yoga 2 Pro, for example, has a few hardware issues that were causing major problems. One with the wifi. There is a module that winds up blocking wifi, and had to be blacklisted so that module doesn’t load. But I found the solution for that in the forums. Likewise, the Intel video on the machine has all kinds of issues. But there are solutions for them, documented in the wiki and the forums. Bit by bit, I picked away at them, and I think I have a really solid, really minimal machine now. There’s nothing on it that I didn’t put there and not much that I didn’t fine tune by hand.
Another side note about Linux installs. It might seem really drastic when I say that I wiped the OS and reinstalled another one three or four times. Actually it was more than that, as there were several experiments in between. Distros I didn’t like and went back to something else. But when you install Linux, you are in control over what partitions are created. I create a home partition that stores all my personal files, and most of the config stuff gets stored there too. In addition to that, there is the root partition where the OS gets installed and a swap partition (and sometimes a boot partition). When doing a new install, you keep your home partition intact. The new OS overwrites the root and boot partitions. You fire up the new OS and reinstall your programs. All your data is still there, and all the config files for the programs are still there, so they function just as they did when you left them – even remembering stuff like previously opened files, options, settings, themes, etc. So reinstalling an Ubuntu-based distro takes 10-15 minutes max. Then you install the programs you want either all at once, or as you need them. At most 1-2 minutes per program. Of course, were I to re-install Arch, that’d be a different story. It was an all-day affair the first time. But most of that was figuring stuff out. It might take me an hour or two now.