The Stripy Strudel's Journal

Subscribe to RSS feed

Posts tagged with "programming"

Do-it-yourself Multicellular Organism

,

I'll try to describe an idea for a computer game that I've had for a while, although the idea is very raw, and only numerous prototyping cycles can answer the question of whether it can be made playable.

The game models the development of a multicellular organism from a single fertilized egg (zygote). The modern science has more questions than answers about how the same genetic information that's copied to every cell in the organism determines the development of a complete organism with complex structure and more than 200 types of specialized cells from a single cell. However, we do know some basic facts.

Cells that have particular functions in the organism are called specialized. Such are, for example, myocytes (muscle cells), neurons (nerve cells), erythrocytes (red blood cells) and many other types. On the other hand, the so-called stem cells do not have a particular function, but they can divide. The zygote is the most universal (totipotent) stem cell which gives rise to all cells of the organism. The first several cell generations after the division of the zygote are also totipotent, but after a few days after fertilization some cells become different from the others — they differentiate. After the first differentiation, the cells are still stem cells, but they are not totipotent anymore. Rather, they are multipotent: they can give rise to many, but not all types of cells in the organism. As the number of cells in the organism grows, their differentiation continues. After a number of such steps, the stem cell finally transforms into a specialized cell of one or another type. The reverse — transformation of a specialized cell back into a stem cell — is impossible in most organisms. An adult organism always contains stem cells in different stages of differentiation. They divide periodically to maintain their own population as well as specialize to replace worn or lost tissue cells, such as in regeneration.

But how does a stem cell “know” what it should turn into? Why don't we end up with heart cells in the brain and nerve cells in the liver? How do the cells making up tissues stick together, and why do organs grow to be certain shapes and sizes? The development potential in a stem cell is regulated by receptor proteins that “monitor” the situation around the cell. At the same time, the cell produces signal substances — ligands — to let others know about its presence. Each receptor is activated by a certain type of ligand and stimulates or inhibits specific processes in the cell, such as production of a particular protein. As a result, the presence or absence of particular types of cells at short or long distances determines the fate of the stem cell: passivity, division without differentiation, differentiation into a certain other type of stem cell, final specialization or even self-destruction (apoptosis). Cells of some types tend to group together with other cells of the same or related type. Special binding proteins (cell adhesion molecules) allows cells to stick to their neighbors and form tissues.

This is an extremely simplified and imprecise description of the development of a multicellular organism, but it's good enough for our purposes, especially because we'll have to simplify it further for the game.

The player's goal is to program the development of a multicellular organism with desired properties by editing the genetic code in the single cell — the zygote. The game does resemble programming, but it's programming with pictures and arrows rather than with lines of code.

The player has access to several types of specialized cells complete with pictures and descriptions of their functions. I'm thinking about flat pictures from the biology textbook, with different types of cells painted in different colors. To get the cell to specialize into one of these types, one needs to start production of a particular substance called a growth factor. The player can create as many other proteins as needed, such as receptors, cell adhesion molecules, enzymes, transcription factors. The proteins get funny names like “tralalase”. By having these proteins activate each other's production, one can in fact program the cell's behavior. For example, for a membrane receptor: “If no doodle ligands are around, trigger production of the munchmunch factor”.

Having specified the set of proteins encoded in the genetic information, the player clicks the start button and watches the organism develop. The protein molecules synthesized in the cells can be seen at a sufficient zoom level. The simulation can be paused, rewound and fast forwarded. To make things simpler, everything happens in two dimensions. By changing the set of proteins and restarting the simulation, the player tries to produce an organism with the desired properties.

Every level has its own requirements to the organism. For example, on the first level the player is to build a semblance of volvox: a ring with a particular diameter made of flagellate cells. The player gets only one type of specialized cells at this level, and has to use cell adhesion molecules to bind the cells together in a ring and receptors to control its size.

The requirements get more complex on subsequent levels, such as to produce a coelenterate with two layers of cells, to create a creature that moves from the darkness towards the light, or to provide for regeneration after minor damage to the body. The number of available specialized cells grows. Because any complex enough structure of the body would require immensely complex cell signaling, the player gets readily available proteins activating increasingly complex development processes, such as a “heart forming factor”. Also, a free modeling mode is available where the player has access to all growth factors and specialized cell types that exist in the game. In this mode, the player can use their imagination to build an organism without particular prerequisites. Players can share genetic codes for interesting organisms in an online community.

I'm not sure such a game is possible to implement. In case it can be implemented, I'm not sure it will be playable. Finally, in case it's playable, I'm not sure anybody will want to play that. In this sense, the idea is even more raw and controversial than my previous idea for a computer game, “Full Speed Astern!” — because here we're trying to model something extremely complex and not completely understood for entertainment purposes. But there is a rather playable game about star formation, why can't there be one about morphogenesis, too?

По-русски: Многоклеточный организм своими руками

Barest Necessity

, , ,

It's well known that while the population of the planet grows, the total IQ stays the same. This applies to Internet users, too. As the number of users grows, the average intelligence plummets, and the software has to adapt. Let's continue the trend into the future and imagine what the browser will be like in, say, 2030. Increase this if you're optimistic, decrease if you're pessimistic.

(Close) (Back) Flickr: art (Reload) // Flickr loves you // (Google | lolcatz (103 000)) (Flickr) (LiveJournal | bradfitz) (Gmail | 14) (Opera Software) (eBay) (facebook) (YouTube)

After numerous improvements aimed at achieving user-friendliness, the browser has become as simple as it can be. It has no menus (neither main nor context), no toolbars with many buttons, no sidebars, no status bar, no dialog windows with settings. All of this was too complex for most users anyway, and scared the poor average Joe away from computers. The future browser will hardly be do a tenth of what today's browsers can do, but it will finally be usable by everyone. Speaking about visual appearance, shadows and rounded corners will still be in fashion. Thanks to the lack of any text in the interface, the browser doesn't need translation.

A browser ships with the operating system, an operating system ships with the computer. A regular user has no reason to change any of these, so the only choice among competing products that he makes is when buying a computer. This choice determines both the operating system and the browser. The browser doesn't even have a name because it's not a separately marketed product. The browser window lacks a title bar because nobody cares about the name of the program. The only button pertaining to the window itself is the red close button, and even that one looks superfluous. The window always has standard size, and web pages are usually designed for that size. Saving of pages and images as well as opening of local files is accomplished by dragging between the browser and the file manager, and printing is done by dragging to the printer.

At the top of the window is a universal field that combines an address bar, a security indicator, a window title bar and a search field. The URL is technical information uninteresting to the user; they only care on what website and what page they are. The website name is automatically verified through its certificate. The only security indication is the color of this bar: green means OK, red means problem. The user can't be expected to know about SSL or domain names, and judging whether the web page is safe enough has to be the browser's job. When it's unsafe, the main working area turns red as well because it's not easy to draw the user's attention. When the bar is clicked, it becomes white and empty, and the user can type in it. The text is always looked up in the search engine (the one with which the browser vendor has made an agreement). If an eccentric user types a URL (where would he get one in the first place?), it will work, too.

To the left of the universal field is the Back button. Its size makes it easy to find. To the right there's a button that changes its function. Usually it's Reload, but during loading it turns into a Stop button (red “No entry” sign), and while typing in the bar it's Go (green right arrow). There's no progress indicator. Instead, while the page is loading, the incomplete document isn't rendered, and the main area displays a “loading” animation instead. It's better to not render incomplete documents because their strange behavior confuses users. Fortunately, thanks to future technologies, loading will rarely take long. There are no scrollbars, either; to scroll, one grabs any part of the page that isn't a link and drags. To find text within the current page, it's enough to start typing.

The bottom part of the window contains eight slots replacing both tabs and bookmarks. Technically they're closer to tabs: each of the eight slots is like a separate browser window with its own navigation history. Clicking a slot activates it, dragging reorders, and dragging a link to an inactive slot opens the link in that slot. The active slot is marked with a contour as well as with the arrow-like shape of the main area. There are always eight slots, you can't add or remove one. A regular user doesn't need more than eight, and the controls for adding, removing and scrolling them would add unnecessary complexity. On the first start, the slots are filled with recommended popular websites, and on subsequent starts they keep their content as well as navigation history. This way, they also replace bookmarks: you can simply keep a frequently visited website in one of the slots.

For the future user, pictures are so much better than text, that's why the slots display website logos. For older websites, heuristics will be used to detect where the logo is on the page, while modern sites will be able to take advantage of the new API. The API will allow the page to tell the browser what exactly should be shown in the slot, and even update that dynamically. In the figure, Google shows the search text and the number of hits, LiveJournal shows the name of the user whose journal is open, and Gmail shows the number of unread messages; the latter keeps updating even in an inactive slot.

The split percent users who aren't satisfied with this functionality will be part of a community going further and further away from the mass market. They will have their own browsers and operating systems. Some of those who develop web services for the mass market will be parts of that community, but most webmasters will use rapid visual development tools close in spirit to the “folk's” browser.

The Russian version of this entry (see link below) features a poll. I have included English translations in the poll and encourage all readers to participate. You'll need to register a free LiveJournal account to vote.

По-русски: Минимум необходимого

A Rant on Friendliness

,

Once there lived a software application that didn't aspire to the mass market and was quite happy with half a percent of permanent users. Those were also rather happy with the application; most of them had been using it since very old versions and developed their own approaches, habits and comfortable customizations. Many of them liked that the application was different from its competitors, and that some of its workflows are unique and unparalleled. But even if the competitors implemented all the same workflows and features, such a user would hardly make a switch because fine customization of an alternative application to one's long-fostered habits to achieve the same level of comfort is a lot of work and not always fully possible. Then, at some point, the vendor of the application is no more satisfied with the loyal but small user base and wonders: our product is better than the competition in almost all respects, and yet we have less than a percent users! Why? The vendor starts researching and analyzing, and it turns out that most users of the competing products think that this application is too hard to use and configure, and in general designed for a technical person rather than a regular user. Oops, says the vendor. We've never had it in mind to design for some kind of technical people! How come our application scares the users? We've been only working on functionality so far, it's time to work on our user interface. Our application must be user-friendly! Friendly to the regular user, that is, to the one who up to now has been using the competing products, being scared by ours. And because those who managed to attract the users obviously have user-friendly interface, we should learn from our competitors. An unusually long time passes between the releases, and finally a permanent user who has been loyal to the application since, say, version 2.0 for MS-DOS, and who is pretty sure that he's the damn regular user, installs a the new version, say, X (that's 10.0 to the new trend). Here is what he finds:
  • Menus, toolbars and keyboard shortcuts are organized in the same way as the competitors have it, including their traditional but illogical peculiarities such as putting “Preferences” in the “Edit” menu.
  • Features unused by 80% users have been moved away to “Advanced”, “Special settings” and “Extra tools”. Especially so for fine-tuning options. The problem is that for every such option, the 20% who use it are different, and in fact, most users need at least one of the relatively unpopular features.
  • Features unused by 99% users have been dropped.
  • Toolbar buttons surviving the purge have grown in size and got text labels, hoping to be noticed.
  • The application started thinking for the user and offering various suggestions, tips and auto-configuration. In severe cases it makes the application seriously slow. It's especially relevant when the user knows perfectly what he means but can't finish typing because the pop-up suggestions get in the way or the application is busy computing them.
  • Wizards with one or two items on each step have replaced dialog windows with all those items at once.
  • There are new features, too, but they are quite strange, don't fit the general spirit and break the design principles of the application. They clearly look like the Professional User Interface Design has been finally applied.
  • New features have sonorous names that tell nothing about what they do, such as EasySnap for aligning objects on a grid or QuickLink for uploading files into a mobile phone. Telling the users honestly what it is would scare them away, so everything should rather be quick and easy, no stress.
  • New features have functional limitations without technical justification. For example, only up to ten user-defined folders: the research shows that the notorious 80% will never need more, while ten fits in the allocated space on the screen without scrolling.
  • Error messages have become as informative as “Some error has occurred”. Of course, 80% of the users have never understood the technical details that the error messages used to contain, but when such a user follows the advise to “consult the system administrator” and calls a friend from the remaining 20%, that guy can only advise: “Try changing some option”.
  • Features for integration with other products or web services aren't implemented as generic mechanisms that could be specialized for any favorite product of yours, but are rather made specifically for the most popular product in its category, which is used, according to statistics, by… well, you know. For example, instead of the ability to use a webmail service for sending messages you get the ability to use GMail for that.
  • The application offers periodically to upgrade itself and sometimes even downloads new releases automatically and installs them, bypassing the system-wide upgrade mechanism (in those operating systems that have one). At least now there's one application for Linux easy enough to upgrade — usually everything is so hard there that it's strange that people even survive.
Of course, this is a degenerated, absurd case. All of this hardly ever happens at once, and the very process of making the interface user-friendly is often distributed over several releases of the application. I don't mean any single application. I remember this happening with different applications and to different degrees. I'm not going to provoke flame wars by naming any examples. I don't know whether this has ever helped vendors win some “regular users” from the competitors, but those who had long been loyal to the application definitely got reasons to try an alternative when the favorite application isn't what it used to be anymore. Every time, having found myself as one of such users, I felt offended by the vendor claiming the revamped interface to be user-friendly. If that's friendly to the user, than who am I? По-русски: Ворчание о дружественности

Escapist Sequences

,

When you use ssh to connect to a remote host, it feels like sitting at that machine's keyboard and screen. This illusion is easy to distinguish from reality: in most cases the console window title will contain a clue, and, most important, there are plenty of ways to detach yourself from the remote keyboard and switch to controlling your own, local machine. One of them is to finish the remote session with the logout command. But there are always other ways you can use in case the remote host is “hanging” and you cannot type “logout”. In ssh, for example, it's sufficient to type the ~. sequence (tilde, dot) starting from a new line to force disconnection. This sequence, along with several others, is an escape sequence that is interpreted in a special way. This is important: all characters are usually passed to the remote host as they are, but an escape sequence is handled by the communication medium itself and never reaches the remote server. If one really needs to type this exact sequence on the remote “keyboard”, there is another sequence for this: a double tilde transmits a single tilde character. All of this means that when it comes to tildes, the transparency of ssh breaks, and the illusion of sitting at the remote machine's console becomes incomplete.

An ssh session is, of course, a weak illusion. It's much more natural in case of VNC, Remote Desktop and similar protocols. They let you use the graphical user interface of the remote machine, and in some cases even hear the sounds made by the remote programs. If you switch to the full-screen mode, the illusion becomes almost complete… but the basic principle remains: there are always some escape sequences (at least one to disconnect) that won't reach the remote host but gets handled by the communication medium. It's often some obscure sequence unlikely to be encountered in the normal course of operation, something like Ctrl-Alt-Shift-Esc that you'll hardly hit by accident. That's why those who don't know about the escape sequences have to use the “natural” method of disconnection by closing the session through the remote OS interface. But, of course, there are cases when it's impossible.

This asks for an obvious analogy with virtual reality systems. The simplest case of VR is three-dimensional image on the computer screen, for example, in games. Distinguishing it from reality is trivial: one has to look around. Escape sequences are usually obvious. A VR headgear generates a much better illusion, especially when combined with sensor gloves and other devices reading back the body position. Nevertheless, even such an imitation is easy to recognize, and taking off the headgear is one of the escape sequences. But what if we go further? What if the system imitates three-dimensional image, sound, taste, smell and even the position of the body in space, and does it so realistically that you can't tell it from the reality? What should the escape sequences be like then?

Firstly, the sequences should be obscure enough not to be triggered by accident. Otherwise we would witness people unexpectedly freezing or disappearing when trying to, say, scratch a heel. Secondly, the sequences have to be available in any situation, even when the body motions are seriously limited, or when some body parts are missing — in these situations it's even more likely that someone would want to exit this world. As to where you end up after such a disconnection, this is something we all get to find out even if we never find the secret escape sequences: everyone will eventually exit the natural way, through “logout”.

По-русски: Последовательности для эскапистов

Full Speed Astern!

, ,

Is there anyone who never played strategy computer games? Even those who aren't fans of the genre know that all strategy games model development. From primitive communism to capitalism, from cabins to skyscrapers, from a village to a megapolis, from a savage tribe to a superstate. This is what all the strategy games I've heard of are based upon. As you advance through them, the infrastructure becomes more complicated, more technologies become available, weapons advance. As a result, all modern strategy games are essentially reimplementations of several immortal prototypes, just with new graphics and sound effects. Among these prototypes are Dune, Civilization, King's Bounty and some others. It's time for something new. So, as usual, exercising my rights as inveterate dilettante and pencil-pusher, I hasten to publish my idea for a strategy game.

In contrast to traditional strategy games, the goal of the new game will be retrogression instead of progression. As we know, progress is not only good for you but also bad for you, and some of its bitter fruits our generation already has to enjoy. Let's make as pessimistic a peek into the future as we can, and we'll have the starting conditions for the new game. The player is entrusted with a country suffering from various negative effects of technical, economical and social advancement. Not a big or small one, just your typical fictitious country with a western-type mentality. The ecology is rubbish, the gene pool keeps degenerating, the national health fades away before your eyes, the society suffers from poverty and unemployment, the birth rate is plummeting down. Without player's intervention, the whole population is doomed to extinction in a century or two, which would be several hours of playing time. The only way to fix the situation is to gradually abandon the achievements of progress: hazardous industry, pernicious technology, unhealthy lifestyle.

Every next mission in the game starts off with a worse situation than before. The first mission has it just slightly harder than what we currently have in Russia. The further, the worse it gets, and closer to the end of the game people live under transparent domes because the air outside is poisoned by hazardous production. They've forgotten how to walk because they get used to individual vehicles since infancy. Nobody can see a thing without glasses with huge lenses. All kinds of information about a person, from the ID to the preferred flavor of synthetic meat, is stored in the centralized database, and one can't even go to the toilet without access to it. Only few courageous couples dare to have kids because the last healthy baby has been born maybe a century ago. Until the age of 6 or 8, every child usually lives in a hospital where they usually undergo primary education — of course, through a computer. Even prohibition of abortion and contraception wouldn't help increase the birth rate because of the popularity of adult entertainment technologies that substitute for the real sex. Prohibition of these technologies as well, and any other prohibitions or sudden changes can easily lead to a sharp increase in suicide rate because, as one might have guessed, a healthy mind is also a rare occasion. As a result, the population would still go down, so there aren't any quick and easy solutions in the game. Ultimately, at the last level, a human is essentially a brain with life support systems connected to the Internet, and it's up to the game developers whether it's going to be at all possible to complete this last mission.

In the beginning of each mission the player is given a goal consisting of several conditions. Each of the conditions has to be met in order to complete the mission. One of the conditions will always be to achieve a certain rate of yearly population growth (though the growth is always negative at start, that is, the population is diminishing). The other conditions are specific to the mission. For example, they can be to bring the infant mortality rate down to a certain threshold, to abandon the radioactive production, to have a thousand people who can walk on foot, or even (at one of the last missions) to have one baby born naturally, without in vitro fertilization or artificial incubation.

A fairly standard set of strategy game tools is at the player's disposal. One can construct and demolish buildings, adjust economical parameters such as taxes, run incentive campaigns that economically stimulate those meeting certain criteria (for example, parents with two kids), change the legislation within certain limits, encourage or discourage some scientific, social or cultural activities, and (this is one of the most powerful tools) use the highly developed mass media to induce one or another way of thinking and acting and affect the popular preferences.

One point is so important that it's worth reiteration: there can be no quick and easy solutions or winning strategies. For example, you can't simply remove the transparent domes because the air outside is poisoned. If you stop the hazardous production that poisons the air, people will starve without the resources they need. This means that an alternative has to be prepared. All transitions have to be smooth, and any radical action does more bad than good. One of the responsibilities of the quality assurance department when testing the game should be looking for winning strategies. Any very simple algorithm that leads to completion of the mission should be considered a grave defect that has to be fixed, most probably by adjusting the weights of various factors and interdependencies in the game model.

Unfortunately, I'm almost sure that this idea will never be implemented. Hardly any game manufacturer will be impressed by it (most probably, they won't even find out about it). But I'd really like to play such a game myself, even though I'm not a fan of strategy games.

По-русски: Полный назад!

Three Levels of Multidimensional Insanity

, ,

When a programmer has nothing better to do, or he just needs an exercise for the brain, he starts having these weird ideas. Like Esoteric programming languages.

All our boring programs are grossly one-dimensional. The memory is linear, the stack is sequential, the program is transcribed in a serialized form. Even things that are naturally two-dimensional, such as the on-screen picture, are reduced to linear for computer processing. The idea of taking programming beyond the one-dimensional space isn't new and has already generated a whole family of esoteric programming languages called fungeoids after the first of the kind, Befunge. The common feature of these languages is transcription of the program as a two-dimensional matrix containing the operation codes. The interpreter moves proceeds from one cell to another in one of the several possible directions. This way, a loop in Befunge can indeed have a loopy look. Some of these languages use memory registers isolated from the program storage space and are addressed by one-dimensional indices; others use the Von Neumann architecture and store data in the same two-dimensional memory as the code, which also creates interesting possibilities for writing self-modifying programs.

The reader might ask why anyone would need any of it, whether someone indeed has nothing better to do, and what kind of mild drugs the author uses, so I'll have to answer. No particular reason. Simply put, it's for fun. Hey, ask some solid scientists specializing in pure mathematics why they have to study objects like… well, not just an algebra, and not even en algebra of algebræ, but an nth order algebra, an algebra of algebræ of algrebræ… n times. I suppose their elaborate answers can be effectively reduced to something like: “Hey, it's fun!” So is an esoteric programming language fun. It's an original joke, and a complicated mathematical abstraction to study, and a puzzle. Taking something to the point of absurdity is fun in itself, so today I've taken it to my hand to carry the idea of multidimensional programming to absurdity. Let's do it in three nonsensical steps. I'll be writing about the two-dimensional case, but it's trivial (?) to generalize for the case of n dimensions.

First level. Here lie the “arrow programming” languages of the fungeoid family. The memory is two-dimensional. In a more interesting variation, the memory is shared between code and data. On this level, each memory cell stores an ordinary number, such as one byte. Let's call the data unit stored in one cell a word, as in traditional computing. Two-dimensional memory uses two-dimensional addresses, such as (i, j). The current instruction pointer (IP) also looks like this. Most fungeoids allow to change the direction in which IP is incremented to one of the four ways, but it's not necessary for Turing completeness: a single direction and a conditional jump to a two-dimensional address is enough. However, the changeable direction of execution flow is the fungeoids' zest which makes programming in them especially unlike the traditional and allows transcribing of loops as rings and linear programs as spirals. Two-dimensional memory organization inspires thoughts of measurement units such as square kilobytes (Kb2), makes you think about what the operating system should do when it gets a request to allocate a wide memory block while only tall and narrow areas are available, and gives rise to an interesting problem of defragmentation of rectangular files in two-dimensional mass storage. The compiler could optimize code not only for speed but also for the area taken, and storage of raster images would be natural as never before. Finally, programming languages can be described by two-dimensional grammars specified in BNF2.

Second level. Unlike the first level represented by numerous fungeoids, I've never encountered anything that would fit my second or third level. In the second level, something strange happens to the very numbers: they are not simple bytes anymore but rather complex values. Addressing a cell of the two-dimensional memory becomes natural. Addition and subtraction are straightforward, multiplication and division are slightly more complicated, and there is a new operation: complex conjugation. One could even go further and say that the cells contain two-dimensional matrices of bits. For example, a word can be comprised of 16 square bits (4×4), which, of course, spawns a new set of arithmetical operations. With regular addition, the overflow bits are carried in one direction — to the left; with two-dimensional addition, bits can be carried both to the left and up. This makes at least two types of addition and subtraction. Shifts and rotations can be done in four instead of two directions, and new operations are possible, such as turns and transposition. When multiplying, shifts are made in both directions. It's not obvious, though, how a two-dimensional word should be interpreted as a regular number for purposes of addressing and counting. Speaking of data exchange in networks, instead of two possible bit orders (little-endian or big-endian) we get eight equally reasonable ways to serialize a word.

Third level. At the third level of absurdity, time becomes two-dimensional. Who cares that it doesn't apply to our Universe? The model is interesting anyway. A moment of time is described with two variables (t, u) rather than one. With regard to a single moment, there isn't just something that happens before or after; there are some moments to the right from this moment in time, some below, and some both to the right and below. The causality spreads in both directions, and what happens in a moment of time is a consequence of both what happened to the left and above in time. Clock frequency is measured in square Hertz, and the state of the machine at clock (t, u) is derived from its states at clocks (t – 1, u) and (t, u – 1). The program stored in the two-dimensional memory runs both horizontally and vertically. In the next clock by t the CPU proceeds to the command to the right of the current, and in the next clock by u it moves to the command below. A bicyclic algorithm can have toroidal topology. In a square second, a communication channel can be used to transfer a number of square bits, therefore the throughput is measured traditionally, in bits per second. The task of optimizing the speed of an algorithm can be defined more accurately: which of the time dimensions is more important to optimize.

Fourth level. If someone comes up with a fourth level to complement the three above, I'd like to discuss it with you before they come to take both of us away.

По-русски: Три уровня многомерного безумия

Bug Reports of the New Millennium

,

Japan aims to create 3D TV that would allow people to view high-definition images in 3D from any angle, in addition to being able to touch and smell the objects

While you're waiting, just think of all the bug reports the developers of this technology are getting right now from their QA. Such as:

Bug #8654534: Roses in test scene 21 smell onion
Bug #8654535: Cannot feel window glass with fingertips
Bug #8654536: After sneezing, sound disappears
Bug #8654537: Toilet paper perceived as too heavy
Bug #8654538: When trying to drink from the faucet, water does not flow
Bug #8654539: [feature] Smell intensity adjustment needed
Bug #8654540: [security] Test scene 50 has holes in the floor
Bug #8654541: After switching scenes, smells from old scene persist
Bug #8654542: [release notes] Fragments of broken glass cause pain in fingers
Bug #8654543: Cannot tear paper by hand when there is writing on it
Bug #8654544: [feature] Vaporizing liquids must increase perceived humidity
Bug #8654545: Very low performance in scenes with multiple PVC layers
Bug #8654546: Can't feel electrcity by touching battery terminals with tongue
Bug #8654547: Stack overflow error in front of the mirror in test scene 44
Bug #8654548: Adding salt to water does not change its taste
Bug #8654549: Books on shelves in test scene 75 have wrong Cyrillic encoding
Bug #8654550: Debug warnings when clapping hands
Bug #8654551: [security] Non-admin can walk through brick walls
Bug #8654552: Segfault when trying to bite barbed wire
Bug #8654553: Snow in test scene 12 feels hot
Bug #8654554: [release notes] Jumping off a moving car causes a crash
Bug #8654555: Cannot eat more than one sandwich in test scene 64
Bug #8654556: All strings on the guitar in test scene 57 make the same sound
Bug #8654557: [top-bayan] Cannabis plant in test scene 18 is not real

По-русски: Bug Reports of the New Millennium

IT Allegory: Afterword

My recent IT Allegory is easy to misintepret in two ways. Or, to put it that way, to conceive two ideas out of it that I didn't intend to convey, and that I don't consider correct in the general case. Specifically:
  1. It is wrong to develop tools that implement fundamental generalizations. One should make small and simple tools to solve the given problem, and no more than that.
  2. It is wrong to make small and simple tools to solve the given problem, and no more than that. One should develop tools that implement fundamental generalizations.
I don't deem either of these a universally correct approach, and it's not to demonstrate the advantages of one approach over the other that I wrote my article for. I wrote it to convey a different idea:
  • It is wrong to adapt a system universal for one class of problems to solve problems of another class. One loses the advantages from the universality and gets the overhead from the overall solution complexity.
This is something that not many would argue about, at least it's much less questionable than the other statement comprising my point of view:
  • For every class of problems, one should undertake a detailed analysis and then develop a system implementing the fundamental generalization for this particular area.
A corollary is that development under strong time pressure harms the product quality while possibly (in the case of a commercial product) contributing to its better marketing success. По-русски: IT-аллегория: послесловие

IT Allegory

At my job I take part in development of certain kind of tools. I love my job, and most of all I like to invent new, universal tools solving whole new classes of problems.

Recently, my boss has assigned me the task to design a new screwdriver. The task didn't contain any clarifications as to what the screwdriver should be like, and, in fact, it couldn't contain any because, at that time, my boss didn't have any clearer vision of the problem than I had. So I decided to design a screwdriver that would be universal in its class of tools (that is, among handheld battery-operated tools — we wouldn't try to compete with specialized stationery machines).

I started by studying all kinds of screws, bolts, nuts, washers, studs, brads and split pins, learned about the specifics of their use. While studying everything relevant to threaded coupling, I figured out for myself something like a common denominator for all the tasks that my universal screwdriver might face: a screwdriver is used for coupling and decoupling of parts by setting one of them in rotary motion. To encompass the entire range of fixing parts, one or two exchangeable bits were obviously not enough. Instead of following the straightforward way of increasing the number of bits (you can't provide for every eventuality anyway), I designed one universal workhead. It could fit parts of different shapes and sizes: from sunken three-millimeter philips screwheads to five-centimeter square nuts. The electric drive allowed to adjust the speed and torque as well as to set the stopping condition (linear distance passed by the part, number of revolutions or strain to reach). It was also assumed that the user should be able to choose from presets for typical tasks instead of setting the parameters manually.

After I was done with the analysis, I started implementing the design. It's not really interesting to describe this because it basically went smoothly. Some features had to be left out until the next version, but it was easy to add them later without breaking anything. The most interesting is what happened a month later, in the final stages of the development. The first to have a suspicion was the UI designer whose task was to refine the look of the prototype. It seemed to him that the handle of the “screwdriver” had too many buttons. I explained to him why this buttons were necessary, and showed how to use the tool in different modes. Then he asked why didn't I just make a bunch of exchangeable bits like everyone does. I explained that a fixed set of bits would never match the abilities of the universal workhead, and, after a long debate, I've been understood, but after that I had to answer a similar set of questions to the head of technical documentation department, and then to a QA engineer. We had to gather a meeting with the manager, the head analyst of the project and other official persons.

In the meeting, another important “little” thing came to light. It turned out that the potential customer doesn't really need to work with the whole range of screwheads and nicks of the fixing parts. They need to screw and unscrew just two or three kinds of screws, but they also want to hammer in nails. With the same tool. To make things worse, the marketing research indicated that the average customer doesn't realize the difference between a screw and a nail, or gets it wrong. As to buttons on the handle, the specifics of the target group imply that there can't be more than two.

Then was the time when one would do a new round of analysis, find a new “common denominator” and design another prototype. But the problem was that there was basically no time left until the scheduled release date which has been already declared in the marketing campaign. There wasn't enough time for all of that, even if you stop eating, sleeping, and going to bathroom. The only possibility left was to adapt the existing prototype to the problem that has changed. This means extension in directions in which there was no extensibility. This means implementation of admittedly suboptimal and short-sighted solutions. This means ending up with something not extensible in any direction anymore, something hard to debug and support, and, of course, with no traces of the initial beauty of approach.

After considering this gloomy perspective, I gave a sigh and took the prototype along with all the blueprints far away. Instead of crippling the existing mega-screwdriver with an axe, I chose to make another one. Not universal at all. Completely inflexible. Able to drive the exactly three types of screws (listed in the new problem statement) in the traditional way — by means of exchangeable bits — and to hammer in nails. Because this new device was nothing but a cliché and didn't have a single non-trivial part, I did it in three days and three nights, or something like that. Only one non-critical part I was able to reuse from the original design: it was the accumulator which didn't need to change at all. The result was quite acceptable — until you want to expand the capabilities somehow.

Why did I choose this way? It's obvious that the simple tool I could make in three days doesn't have any flexibility, scalability or extensibility. True, but the old prototype adjusted to the new problem wouldn't have it either. It's flexible but not to those angles, it's scalable but not by those parameters, it's extensible but not in those directions. It's natural — because it's impossible to design an Ultimately Universal system. If you need something universal, you have to answer the question first: what do you have to encompass by this universality? An incorrect answer, or one that later turns out to be incorrect, leads to waste of time and effort. An attempt to apply a system which is universal in one area to encompass problems from another leads to loss of all advantages of the universality, but does increase the overall complexity of the solution. If you can't do it the right way, it's better to do it the wrong and simple way than the wrong and complex. What can be done in three days, can be even redone from scratch, if necessary.

The first prototype still rests in my desk drawer. Maybe I'll still have a chance to dust it off someday?

По-русски: IT-аллегория

Not Every Bug is Bad

,

For once I've had a dream that isn't complete nonsense. What happened in it could as well have happened in reality.

Here is what I've seen. Some company X (there wasn't a specific name in the dream) had captured a huge share of the mobile phone market. Nearly every second phone in the country was their model Y. There was only one point that X lost to the competitors: others had platforms for user-downloadable applications (some had Java, others had Symbian) while X didn't have any such platform. X could release a new phone model, but most users were currently happy with Y, and few would buy a new phone just for the downloadable applications. However, X wanted to make money on downloadable applications. They'd considered free firmware upgrades in service centers, but this option wasn't good enough: service centers in a big country work slowly, and users would have to wait for weeks to have their firmware upgraded, so hardly many of them would use the service. (This is actually true. When my phone needed reflashing as a warranty repair, I got it back from service after a month.)

The solution that had finally been implemented was found by programmers, not marketers. One of them, having heard of the problem, made a suggestion as a joke, not actually hoping for it to be taken seriously. This programmer happened to work on the Y firmware source code, modifying it for use in the future model Z. While reading the code, he had found a bug in the code that handled incoming chained SMS messages. A specially crafted chained message could cause a buffer overflow with a theoretical opportunity for the attacker to execute arbitrary code. Nobody knew about the bug, and the chance for it to be triggered accidentally was one in a billion. The programmer's idea was to use the vulnerability to upgrade the firmware remotely.

And that was what they did. Of course, the users weren't notified of the vulnerability. Company X had simply offered all users to do a “remote software update for the mobile phone” for a symbolical fee of $1, promising that the update will add new features to the phone, including the ability to download applications. To perform the update, a user had to send an SMS to a special number (so that someone couldn't order a surprise upgrade for a neighbour). In reply, the server sent the user a chained SMS message exploiting the vulnerability. It consisted of several chunks and contained a bootstrap loader. The loader used GPRS to download the new firmware from the X server (the $1 was actually used to pay the cellular carrier for this GPRS traffic). After a checksum verification, the loader installed the firmware into the flash memory and restarted the phone. (To prevent incomplete reflashing because of weak battery, the loader told the user to connect the charger to the phone.) Besides the support for downloadable applications, the new firmware contained other improvements. One of them was a fix for the vulnerability so that nobody else could ever exploit it again; the other was the ability to download firmware images over GPRS and install them (after checksum verification, of course) — just in case.

По-русски: Не всякий баг вреден

You are in a Maze of Twenty Little Passages

,

There is a text-based adventure game Dunnet packaged with GNU Emacs — you must remember those games where you read descriptions of the rooms where you are, and type commands like put key in door. If you have Emacs, I recommend you this one. This is, I tell you, cyberpunk.

For example, there is a room with a computer. It runs some flavor of UNIX with a crippled but working shell. The /rooms directory contains a subdirectory for each already visited room with files representing objects currently located in those rooms. Your current inventory is in the home directory. What you have to do there is to transfer all your stuff to a remote server over FTP and then use rlogin to get there yourself. After doing this, you find yourself in a room called “Receiving room” (without any computer), and all the objects transferred here are lying on the floor nearby. It's funny that if you forget to enable the binary mode for FTP, you'll find a worthless pile of protoplasm instead.

There are a lot more places like that in the game, though. Highly recommended.

PS: Check this commit in the game's CVS.

По-русски: You are in a Maze of Twenty Little Passages
May 2013
M T W T F S S
April 2013June 2013
1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31