Software Engineering - Starter Web app 1

The purpose here is to go over some basic web stuff and get a server up and running, with maybe a web interface. legend terminal commands A source block with a $ in front generally means this is a command you should run as your normal user from within a terminal or shell. Commands on your system are programs, and you should either only run commands you understand and/or originate from a trusted (by you) source. If the command is prefixed with a # it means to run the command with elevated permissions, such as the root user or as a sudoer using sudo. Generally commands that want elevated permissions should be treated with greater scrutiny. ...

2018-06-13 · 11 min · 2250 words · Logan Barnett

Killer Queen

I’ve played some Killer Queen and helped put together streaming. Though the tech for Portland’s streaming setup has dramatically improved, the streaming guide is left up for posterity. Killer Queen black box study Killer Queen streaming guide

2018-01-14 · 1 min · 37 words · Logan Barnett

Killer Queen Black Box Study

Table of Contents changelog introduction background reasoning things frames history complications the operating system the solution side by side conclusion frame rate the problem enter vsync does KQ use vsync? TODO show example of vsync pixels 2D as 3D what about the pixel graphics? TODO conclusion TODO the wrap glitch game stutter TODO the “drip” collision characters changelog <2018-06-05 Tue> add section about character controllers. <2018-03-22 Thu> add section about game stutter. <2018-01-21 Sun> add section about frame rate and vsync. introduction At the Portland scene we like to talk a lot about different things we’ve learned about Killer Queen, and being that the game is effectively a hunk of software we wind up talking a lot about details of its internal implementation. This post is about the software implementation we know about Killer Queen or things we are able to infer about said software. The source code for Killer Queen is locked in a vault somewhere, guarded by a small army of the best speed warriors. As such we can’t say for 100% certainty about everything. The game is a black box where we cannot see inside it. We can make some good guesses though. ...

2018-01-14 · 19 min · 3851 words · Logan Barnett

The Ultimate CI/CD Setup

1 introduction CI/CD stands for Continuous Integration / Continous (Delivery|Deployment). Roughly when we refer to this, we’re talking about an automated build/test/deployment suite of tools. Virtually all of your big programs you write are useless if they just run on your personal computer. You need to put them somewhere so they can run when your computer is off, or other people need to be able to use the software you made. So we need to deploy the software somewhere, and the software needs to be consumable in a way that doesn’t require your machine’s development setup for those who need to consume said software. ...

2018-01-01 · 12 min · 2346 words · Logan Barnett

Killer Queen Streaming Guide

Table of Contents introduction changelog - <2018-03-26 Mon> challonge integration workarounds video flow audio flow pdx setup facilities hardware video audio all together now anti trip trick software challonge kq-tournament OBS troubleshooting The USB webcam freezes after transmitting for a little bit If the input is not recognized on the computer’s end introduction As part of trying to reduce the Portland scene’s bus number in regards to our streaming setup I’ve recorded notes here as best I can. The dream is to have a pretty foolproof setup that anyone mildly technically competent could apply to their scene’s cab. People can and should provide suggestions and corrections so our community can better thrive. As a general policy I won’t use a comment system on this site because static hosting is awesome and also because echo-chamber.js makes an excellent point. Feel free to contact me via email, Twitter, or carrier pigeon for any improvements we can make here. ...

2017-11-05 · 8 min · 1608 words · Logan Barnett

Painless(er) Unit Tests

Table of Contents How to Make Unit Testing not so much of a pain Unit Testing Primer Dress for Success Do not DRY your tests Test Driven Development Keep your tests Assert a single truth per test Clearly state your intent Avoid blob tests Use acceptance tests instead Or use an algebraic type system instead Admissions Conclusion How to Make Unit Testing not so much of a pain Unit Testing I find myself talking a lot about unit testing in my current workplace. Over time I’ve learned things from others as well as developed some habits that have served me well. I’ve gotten applications up to 100% test coverage without Herculean effort. Granted, test coverage is not the same as test quality, it’s still a useful metric. I’ve demonstrated that there is at least one case in which my code can work. ...

2017-05-17 · 9 min · 1802 words · Logan Barnett

asteriod generation

Introduction For my personal project, I’m working on a simple and relaxing asteroid mining game. It spent a long time as a prototype, simplified from many other voxel-based games into this one, which feels realistic to achieve. I’ve been working on it and the tech around it for years, with irregular spurts of activity, lots of abandoned paths, and much thrown away work. My plan is to use WebGL in some form and deploy it to the desktop via the web (or even Electron), and use Cordova to handle the mobile version of it. Since it’s faux 2D with voxels, I think mobile is a viable target. This is pending tests. Mobile or not, this game needs to be made. I realized this when I was testing the old Unity prototype, and found myself getting lost playing it long after I’d tested whatever functionality I was curious about during that run. ...

2016-08-17 · 4 min · 851 words · Logan Barnett

verification

Unit tests, type checkers, SAT provers. These are all tools we use to verify our code, and it’s by no means an exhaustive list. People struggle with using them though. Ruby and Python engineers typically find static type systems too cumbersome. Instead they favor more unit tests (those that do unit testing). C# and Java engineers generally like the benefits of static checks to make sure interfaces are respected (except null - seriously wut r u doing?). On the more extreme end you have tools like Haskell that are statically typed in a way C# and Java engineers can’t even wrap their heads around without major study. ...

2016-05-28 · 4 min · 796 words · Logan Barnett

Aspects of Functional Programming

For all of the flak Javascript gets, there is one thing it has above all of the “better” mainstream languages out there. I’m talking Java, C#, Python, Ruby (yeah you two are mainstream to me). Javascript has functions as first class objects. As a result, Javascript has been my gateway drug to functional programming. Functional programming has a lot of interesting promises to it, but it’s been damn frustrating at times to learn. Everything is so damn generic that it’s hard to understand when it’s time to pull out certain patterns/functions/operations, at least as an outsider looking in. I’ve really stuck with it, and it feels like it’s gotten better over time. There’s still much for me to learn, but I feel like I’ve climbed over some humps. ...

2015-11-30 · 8 min · 1640 words · Logan Barnett

Destroy Meetings

Who hasn’t wasted tons of time in meetings? Meetings are a joke in all organizations, and the joke is always the same - they are meaningless wastes of time. I’ve heard the sweet promises of things like Scrum, pomodoros, people slapping you in the face when you open Facebook all as means to reduce waste in the workplace. The thing is, none of them are nearly as damaging as meetings. The reason we have meetings are noble ones, but misguided in their attempts to solve a problem. Short of a masquerade for some political agenda, meetings have a singular purpose: share information. Information sharing is hard and how many of us are just awesome at writing documentation constantly? How about grooming that documentation and making sure it’s well organized? As a result, people are left out of the loop. They want to form a meeting so they can ask questions and get people nodding heads on the path forward. The problem is that even with meeting notes, real documentation hasn’t been made. The information exchanged in a meeting is transient to the members of the meeting, and even then only to their recollection. Meeting notes without context are meaningless, and meeting notes don’t really contribute to a growing knowledge base - they are a log more than anything. Someone kept minutes. ...

2015-10-05 · 3 min · 564 words · Logan Barnett