Recently the Factor programming language had a new 0.98 release, after a 4 year hiatus after the 0.97 release. Finding this on lobsters, I decided to take Factor for a spin again, after years of having left it mostly alone to work on PISC. I decided I wanted to try to build a (still slightly buggy) 4-function calculator, as I find that a good way to gauge how easy/hard it is to use a GUI system for small things, and as a way to gauge what Factor is like in general.

The (quite frankly) awesome

1) If you’re developing apps on less than common Android phones via Andriod Studio, like the One Plus One (my device), then using the ADB network bridge will save you having to figure out which set of drivers you’d need to actually be able to connect to the phone via USB. It is cautioned against if you’re on an untrusted network, and at least the One Plus One has you confirm that you want to create a debugging connection, but it does seem a bit handy.

A while ago, I decided to self-host the PISC repository using Fossil, mostly so that PISC could be easily self-hosted on hardware that I own, rather than relying on Github. Until now, this meant that to play with PISC, you had to either install fossil (which isn’t hard, but is an extra step), or content yourself to a tarball/zip file.

As of this morning, there is now a Github based mirror repository. While I don’t intend to do my main development and documentation there, I will accept and work with issues and/or PRs there (such as I have time to do).

Every programmer has a favorite toy problem or smallish program idea that they like to use to try out new tools. For quick testing of GUI tools, mine is a 4-function calculator. This fascination started at an early age, when I was programming QBASIC at the age of 14. I wrote one in 15 lines of code that prompted for the first number, operation and second number. When I moved on to Envelop Basic, I created a GUI calculator with three text boxes, two inputs and one output, with a button for each of the 4 operations.

Then, as my family was traveling from Kansas to Florida in 2011, I was introduced to Petzold’s CODE, and advised that C# would be a good language to pick up for finding jobs. One of my key discoveries working in BASIC during my teenage years was that I had to have a project in mind if I was going to get any programming really done. So I decided that to learn C#, I would build as much of a scientific calculator as I could figure out.

DOM attributes are a little strange from JS. When you iterate over them using the attributes property, all the names come back completely lower cased. When you fetch them using getAttribute(name), the attribute name argument is completely case insensitive.

I had the opportunity to visit my parents in Papua New Guinea this summer, and it was an awesome trip. It gave me a chance to clear my head and get away from the constant stream of information and distraction that is so baked into life as an American technologist. It also gave me a chance to get a perspective on what missionary life is like.

One example of life overseas being just straight hard work is the sheer amount of moving that is involved. First, you have to pack up your entire American life. Every. Single. Thing. All your books, clothes, cars, shoes, plates, food and everything has to be dealt with in some fashion.

I am a programming polyglot. While I work by day in C#, I have wandered far and wide in my own time. Each language and surrounding ecosystem I’ve tried has a different strengths and weaknesses*, but one stands out as disappointing to work with overall: Java.

Java, the language, is a little bit on the verbose side, and a little split-brained in how it treats primitives vs classes, but it’s very far north of tolerable, especially as generics and such have been added over the years. Java, the ecosystem, on the other hand, is a case study in making things more complicated and painful than it needs to be, especially on Windows.

So I had a bunch of ideas for Ludum Dare 36, as I tried to come up with an idea for each idea. As luck would have it, the theme was the one that I didn’t plan for, but these ideas could still be made to work. (Edit: I wasn’t able to finish anything for LD 36 due to life getting in the way)

Lately I’ve been trying to learn how to run more than one web application on a web server. I understand this often involves using nginx as a reverse proxy. I’ve been interested in rewriting my blog in Elixir/Phoenix, but I want to keep the current blog up while I’m making the changes. So I’ve been stumbling through nginx reverse proxy tutorials. I will be taking notes into this post about various things that I’ve learned about how to set up nginx as a reverse proxy for golang applications like this blog.

I was reading an article written by a linux sysadmin about the trials of good file organization. After trying various hierarchical schemes, he settled on an interesting one: Storing files by Date, in folders. I’ve also just learned about Engineering Notebooks, where ideas are logged for a company, and dated by page.

I decided to try something similar with a pile of documents on my current laptop. Hence, the following PowerShell script, run over several file extensions typs (see *.jpg).

My job has had me working on service applications that run on a timed interval. One aspect of debugging these services that was slowing me down was waiting for the service to get triggered. For the longest time, I compensated by having the service be in on a 10 second timeout, since it didn’t take very long to run a sync. This still slowed me down though, and it made it easier to get sidetracked while waiting for the service to fire.

The solution didn’t strike me for a good 3 months: Add a way to trigger the service on demand. It is a very obvious solution in retrospect. And it makes a lot of difference when debugging, as I can fire off the service as much as is needed to test for different states.

This is a helpful little function that I wrote when I found out about the System.Diagnostics.Debugger.IsAttached.aspx) property. I found it useful for debugging a synchronization service that I was working on at work.

EDIT: These are rather old compared to what I’ve had time to do since.

Below are some links to some of the more interesting programs that I’ve done for school. None of these programs necessarily represents my best work, but you find might them entertaining or educational. This list will get updated as I add more of my learning-experience programs online.

Verse

Thank you for reading my blog.
This website is currently done on my spare time, often during late nights (like much software). Because of this, there’s occasional bugs and ugly pages. I’d love to know when that happens, so that your reading experience isn’t sullied by it.

Every programming framework has certain corner cases suck the performance out of an application. The .Net Framework is no exception. I’ve discovered a few in my work with C#, and blog about them as I find time.

I love using regex for search/replace/text manipulation tasks in programming. You don’t have to go to full perl mode for the awesomeness that is Regex.Replace("(\w+)-(\d+)", "$2-$1");. This awesomeness is counter-balanced with the risk of catastrophic backtracking when using the non-regular varieties of regex, like Perl, Javascript and, most pressing for me, .NET.

Note: This is a piece that I wrote towards the beginning of my time in Bellingham. I plan another article soon as I am on the other side of my internship

The world is a bigger place when you have to walk everywhere. This is my profound discovery of these first few days in Bellingham. Walking is one thing that I’ve done a lot over these past few days. It gives you a different perspective on life. I’m thankful to the many drivers that have stopped for me to cross the road these past few days.

One of the things that I’ve been blessed with is the opportunity to start programming from a young age. What follows is the start of that story, what abstractions and tools I picked up then, and what crazy things I was trying to do with them (more than I knew what I was getting into, usually). This post covers the 12-14 year old me learning ropes of programming (as remembered 8 years hence).

The Olden times: QBasic and Boy Scout Magazines

I started in programming for the same reason as many others: I had video game ideas that I wanted to make on the computer. My father, a Bible translator, set me up with QBASIC. My textbook was a pile of Boy Scout magazines that I found in the kid’s room at the Pioneer Bible Translators offices.

There are stories of rubber ducky (or teddy bear) problem solving, where the only thing that a person needs to do to solve a particular problem is articulate that problem to someone else, or in this case, something else. This leads to stories of engineers being able to solve their problems by explaining them to inanimate objects. When I explained this to my family, I suggested that I might want a rubby duck for Christmas, so that I would have something to explain my programming problems to.

So it was great fun to get a rubby duck for Christmas from my sister. She added a little story to it, projecting what Jules (the rubber duck) would be doing with me as I work on my programs. (She hadn’t read the wikipedia article that I linked to.)

I have a very active mind. As a home schooler, I read around 1000 books (of various lengths) between learning to read and graduating. I also tend to have at least one program/board game/story idea percolating in the back of my mind. I started programming so that I could build a few of those ideas.

The creative process carries a great deal of intrinsic motivation. But there is also a mechanical side to programming that can’t be escaped. The mechanical side of programming is where a program gets its polish, but it can feel a bit gritty and tiresome at points. I find that it happens when performing ports to a familiar technology, or when writing yet another simple* SQL Query (YASSQ).

Every programming framework has certain corner cases that can drain performance when mishandled. The .Net Framework is no exception. I’ve discovered a few in my work with C#. I’ll be blogging about these as I find them.

These are not micro-optimizations like using String.Concat instead of += "" over a small string. These problems will suck the performance straight out of your application, and are inconspicuous in the code, requiring a some kind of profiling to realize what’s going on.

My brother and I rolled dice and commanded armies, testing our strategy against the wits and armies of Kaser the Kaiser, as he like to call himself. Wars waged went back and forth over the RISK board, to the sound of much hilarity, fun, and explanation of rules. My first RISK game, colored by nostalgia and entertained by the fun nature of Mr. Kaser, seems like one of the funnest ones I've had. The people you play with have a dramatic effect on your board gaming experience.

Since then I've played RISK several times, but over time I've realized that it is a game that is fundamentally drawn out. My relish for RISK has faded with experience. I've moved on to other games that have more intrinsic fun, like Dominion, Settlers of Catan and Race for the Galaxy. These games bring better pacing, balance, and variety to family game night. But you can't escape the importance of the chemisty with your fellow gamers.

Disclaimer: None of the SQL refers to data that I use at work. They were inspired by golang's database/sql package documentation

One of the things that I've been learning as a programmer is what well factored code looks like. There are several concerns that go into it, but one very important part of well factored code is the principle of Don't Repeat Yourself (DRY). The net result of DRY is that when you only have to write the unique elements of your code, removing repetitious noise. This helps you focus on actual differences in code, instead of trying to to filter the signal out of the noise.

In the Kingdom of God, obedience is worth more than skill. God is more than able to make up for our deficiencies. These are some things that I've known to be true on a mind level, but lately God has worked in me to help sink into my heart. When we go on our own skill, the best we can do is be something that the world could have produced on it's own. Thus we have people that do "good" things, whether by temperament, a guilty conscience or civic duty. We end up reflecting ourselves, in all our human fallibility, and will disappoint those who see us.

But God has not called us to run on our own skill. He has called us to obey his calling. His calling is not always comfortable, nor is it always tame. Regardless of how strange or difficult his calling is, he will provide for it to be fulfilled. When we are in tune with the Holy Spirit and obeying him, we don't run on the stuff of this world. The stuff of this world doesn't produce superhuman results.

I’m Andrew Owen. My universal web handle/mascot is yumaikas, (pronounced you-MIKE-us) a Papua New Guinean tree said to resemble a boy caked in dirt, pouring out rivers of sweat over white skin. I program, pray, and think; sometimes the result is worth discussion.