Originally posted as a comment on The Jimquisition site on an article about buggy and poorly performing PC ports of games.
-------
I am not a game developer, but I am an experienced software engineer who works on web applications. I cannot count the number of problems that I've brought up with management that have been ignored or put on some list of shame that we want to fix, but the whole list is then ignored. I would guess that the engineers and QA people knew exactly about the stuttering problems in Arkham Knight PC port and some people on the team could have fixed them, but they were not given the time to do so. Problems I've most often seen ignored are: security holes, performance problems, rare (or perceived as rare) bugs, and unusual or slow platforms. Of course, these line up perfectly with the highly public fuck ups we've seen from games developers.
The Greedy Programmer
Friday, 17 July 2015
Thursday, 1 May 2014
Shell script one-liner of the day
It continues to amaze me how powerful one line of shell script can be.
Here's one I used this morning that'll checkout from git the directories containing a certain keyword at a particular revision in the past:
rev=abc12345; git ls-tree $rev | cut -f2 | grep -i keyword | tr '\n' '\0' | xargs -0 git checkout $rev --
Yes, it's ugly, although I imagine that better script programmers than me could clean it up significantly (writing this I already figured out how to trim the tr command from the pipeline). Yes, it relies on several slightly odd text processing tricks and implicit knowledge, each carried out by a different executable. But it's undeniable how quick it is to do fairly complex things in shell, which an exclusive GUI user could only dream of.
What makes this possible is just a few shared ideas:
- Processes have an input and output stream and the shell can pipe between processes
- Sequences of items are represented by text delimited by null or new line characters
- Fields of an item are represented by text delimited by tabs
Then we have our few simple tools:
- git ls-tree outputs machine readable text
- cut selects a tab-delimited field from an item, where each item is on a new line
- grep filters items based on a regular expression
- tr transforms each item and outputs it again
- xargs runs a command once for each item in its input
- git checkout does its job with parameters from the command line
This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.
Monday, 3 December 2012
Rant: Hardware and virtualization vs software compatibility
Hardware technology and virtualization have progressed to the point that we can now brute force software incompatibility annoyances.
As an example, you can't install IE6 and IE7 on the same machine, but you can install and run two separate complete virtualized copies of Windows XP, each with a different version of IE. This is like asking, "Can I swap out the radio in my car for another radio?" and being told, "No, but we can install a number of precise miniature duplicates of your car in cages on the back seat, each of which can then have a different radio."
I love virtualization, and think it's very powerful tool, but in cases like this I feel the software industry has lost a battle against its own complexity.
As an example, you can't install IE6 and IE7 on the same machine, but you can install and run two separate complete virtualized copies of Windows XP, each with a different version of IE. This is like asking, "Can I swap out the radio in my car for another radio?" and being told, "No, but we can install a number of precise miniature duplicates of your car in cages on the back seat, each of which can then have a different radio."
I love virtualization, and think it's very powerful tool, but in cases like this I feel the software industry has lost a battle against its own complexity.
Saturday, 2 June 2012
I decided to add a few bits of code that I have lying around to github. Feel free to check them out: https://github.com/fluffysquirrels
Sunday, 23 January 2011
Facade pattern vs Adapter pattern
It seems common for programmers to consider the Facade and Adapter patterns very similar or identical (example). However, there is intended to be a subtle difference between these two Gang of Four patterns.
The Adapter pattern is used where you are wrapping an existing object (Adaptee) with a new class (Adapter) that is to be used by an existing client. The Adaptee has a different interface than the client is expecting and we need to fix that. Eg wrapping a set of classes implementing a memory-based filesystem with new classes that fit the file interfaces expected by a client.
The Facade pattern is used to wrap an existing object with a new interface that is easier to use than the existing interface. The consumer of the facade can then be simpler. Eg writing a 'save' method that will open a file, write some data to it, and then close the file.
The save method barely consists of a new algorithm, we're just gluing a few existing file functions together. If there were a new algorithm or some new interfaces and data structures, I would say there was too much code to call it a facade.
I admit that the distinction is small.
The Adapter pattern is used where you are wrapping an existing object (Adaptee) with a new class (Adapter) that is to be used by an existing client. The Adaptee has a different interface than the client is expecting and we need to fix that. Eg wrapping a set of classes implementing a memory-based filesystem with new classes that fit the file interfaces expected by a client.
The Facade pattern is used to wrap an existing object with a new interface that is easier to use than the existing interface. The consumer of the facade can then be simpler. Eg writing a 'save' method that will open a file, write some data to it, and then close the file.
The save method barely consists of a new algorithm, we're just gluing a few existing file functions together. If there were a new algorithm or some new interfaces and data structures, I would say there was too much code to call it a facade.
I admit that the distinction is small.
Sunday, 19 December 2010
Why using the Internet is like walking to the post box
I believe strongly that analogies are powerful tools when explaining detailed and technical topics. Therefore, I have planned an experiment: I will try to explain a non-trivial segment of computer networking with analogies to everyday items and occurrences. I hope this method will be less threatening and more fun than a text book while still explaining some technical facts about networking and helping people solve computer problems. Of course, it will also be an excellent opportunity for me to consolidate my technical knowledge and practice my writing, I cannot pretend to be selfless here!
Let's drive straight in. This is what my wireless router looks like. It's the box of tricks that plugs into my phone line and lets my computer connect to the internet. What does it do and how does it work?
My first analogy is that the internet is like the international post network. What's the first step in using each? Once I've written a letter, I take it down the road to my local postbox; similarly, once my computer has prepared a packet (a small letter-sized batch of information) and wants to send it somewhere on the internet, it takes it to my router.
Besides both being the first stop on the journey in each networks, there are a lot more similarities between postboxes and routers. Once I've posted my letter, I've entrusted its delivery to the Royal Mail (the postal service in the UK) and I will play no further part in the process. Royal Mail will pick up the letter from the postbox, take my payment in the form of a stamp, and use the letter's destination address to get it where it's meant to go. Once my router has my computer's packet, the computer trusts the router to forward the packet to Be Broadband, my Internet Service Provider (or ISP), who will then get it where it's meant to go by considering the packet's destination address. I pay my ISP monthly by credit card instead of with stamps, but apart from that they are quite similar to the Royal Mail.
There are many other ISPs to choose from, just as I can send mail by UPS or FedEx. Further, each mail company will accept my letters and each ISP will take my computer's packets. I can choose my provider because I adhere to standards: my letters are a certain size and weight and I wrote the return and destination addresses a certain way, my computer's packets also have a certain structure and a standardised return and destination IP address.
The Internet's standards -- its protocols -- are more numerous, intricate, and rigidly followed than those of the Royal Mail. Those attributes increase the complexity of learning them but also their utility: a letter may fail to be delivered because it was accidentally dropped on the way to a delivery office, but a packet will typically fail to be delivered for a much more specific and often more correctable reason. This allows a knowledgeable computer user to get a job and hence receive money, or to help out family and impress friends, and hence receive cake. If you ever want proof that reading about computers is worthwhile, just remember the cake.
Here's a summary of the technical lexicon covered so far. Next time we'll learn some more terms and get into the meat of some protocols.
Term | Post analogy |
Internet | International post network |
Internet router | Local post box |
Packet | Letter |
Be broadband (my ISP or Internet Service Provider) | Royal Mail (my postal service) |
IP address | Postal address |
Internet protocols | Postal standards |
Subscribe to:
Posts (Atom)