Thursday, September 28, 2017

September 28, 2017 at 07:41PM

Today I learned: 1) ...about Stéphane Leduc's experiments in osmotic growth. Back in the 1910s, Leduc (and, I gather, a few others before him) discovered that if you put a seed crystal of one salt in a solution that's highly saturated with another salt, you can make a "cell" whose membrane is a layer of flexible, colloidally-precipitated salts. Osmotic pressure causes the "cell" to grow, sometimes in quite fantastic shapes... including many that are startlingly similar to living organisms we're familiar with. Leduc came up with osmotic growth recipes for single cells, cell colonies, ferns, mushrooms (complete with caps and gills), trees, tube worms, shells, and other things. Leduc actually hoped to show that osmotic pressure was the fundamental force responsible for life. In that, he was grossly mistaken. It's something of a cautionary tale for fundamental biologists, or even scientists in general... just beacuse you have a simple model that reproduces the patterns of a phenomena DOES NOT mean that you know what causes that phenomena. (On the other end of the spectrum, there are Turing patterns, which as far as I know were a) totally mathematical structures that b) turned out to be quite descriptive of things like shell and fur patterning.) Check out some photographs of Leduc's growths here: http://ift.tt/2x0uFC1 If you want to know more, you can read Leduc's book on the subject here: http://ift.tt/2wmfIdJ. I've only read a small excerpt, so I can't speak to the whole book, but it's worth at least looking through the plates -- he took some really gorgeous photos of crystal growths. He also gives a few recipes in chapter 12, so if you want to do these yourself, you can (some of those salts are toxic, though -- DO NOT mix the salts with or on anything you're going to use for cooking!). 2) Arrow's Information Paradox, a, uh, theorem of economics? A hypothesis of economics? Anyway, Arrow's Information Paradox deals with the supply and demand of information as a good. The paradox is that it's very hard to know how valuable a piece of information will be unless you know the information. So if some kind of information is available in an open market, and you're trying to decide whether or not you should buy it, there's no great way to decide without getting the information, which you can't do without buying it. The net result is that a free market is likely to mis-supply (probably under-supply?) information. Arrow's Information Paradox is one argument that knowledge should be treated as a public good and funded accordingly. 3) Wikipedia has a fairly pretty severe gender balance problem -- only about a third of Wikipedia visitors and only about 10-15% of Wikipedia editors are female. I was quite surprised about this. There are a whole bunch of interesting nuances to this overall fact -- for more, check out Wikipedia's article on gender bias on Wikipedia: http://ift.tt/1AnbVMx

Friday, September 22, 2017

September 22, 2017 at 10:25PM

Today I learned: 1) One of the major bacteria protein secretion tags works by getting itself inserted into the plasma membrane and esposing a motif that's recognized by a membrane-bound protease. The motif gets clipped, the tag stays in the membrane, and the rest of the protein floats away. 2) GFP doesn't really work in plants. Chlorophil blocks either GFP's absorption or its emission, and plants typically have a lot of chlorophil. Instead, the standard plant reporter is (one of the many) luciferase(s), which produces a fluorescent small molecule. Unfortunately, luciferase doesn't really work unless you express it in the chloroplast. I don't know why. Something about "metabolism". Anyway, even *more* unfortunately, the "express luciferase in the chloroplast" technology is under patent, so you can't really make glowing green plants for commercial use. =( Fortunately, it doesn't matter much, because 3) There's a class of lipids that act as membrane-specific markers for eukaryotic cells. I can't remember their name right now, and I can't find them, so I'm just going to call them marker lipids. Anyway, there are several (about a dozen) variations of marker lipid, and each is used by the cell to label a different kind of membrane, i.e., marker type I goes on the nuclear membrane, marker type II goes on the endoplasmid reticulum, marker type III goes on the plasma membrane, etc. That's how the cell can correctly insert stuff into the right membrane -- a lot of membrane insertion will only happen on membranes bearing the right marker lipid, and some proteins don't function unless they're bound to the right marker lipid. How, then, do the marker lipids get into the right membrane? Well, they can all be interconverted by a bunch of different enzymes, and those enzymes are *themselves* bound to the right membrane. So, using my example marker lipids above, the enzymes that turn other marker lipids into marker type I are found on the nuclear membrane. That way, just about any marker lipid can go into just about any membrane, and will eventually be converted into the right kind. How, then, do the marker-lipid-converting enzyems get into the right membrane? They recognize the marker lipids, of course!

Wednesday, September 13, 2017

September 13, 2017 at 04:07AM

Today I Learned: 1) ...dependency graphs matter. Bungie's Chris Butcher has a wonderful talk on asset processing for the game Destiny. In short, Bungie built a nifty asset compiler that let them build, on a PC, a compressed binary of the game so that developers and artists could check out their changes, in a final context, with the game's final memory layout. The problem was, the system made it really easy to link together dependencies. Imagine, for example, that some object (perhaps a system that highlights enemies) wants to know the bounding box for a crate. The compilation system then would go compile the crate and return the bounding box. But wait! In compiling down the crate, the system would need to know about the shader used by that crate. So it would compile the shader, too. Which would mean compiling every object used by the shader. And so on. Basically, it was really, really easy to end up compiling the ENTIRE LEVEL any time an artist made any change, which meant that artists would have to wait hours to see the results of every change. Not cool. The lesson? Compilation dependencies are dangerous things, especially if you let people who don't understand them VERY well start to add them. For more details, see: https://www.youtube.com/watch?v=7KXVox0-7lU 2) Lamins are a class of protein that's critical to the proper formation of the nuclear lamina, which is a sheet of proteins that coats the inside of the nucleus's plasma membrane. The nuclear lamina is really important for proper DNA spatial organization and replication. If you have missing or malformed lamins, you get progeria. Today I learned that lamins are unique to animals. Plants, fungi, and protsts don't have lamins. They DO have nuclear lamina -- they're just made with different proteins. 3) Speaking of lamins, today I learned that lamins and laminins are NOT THE SAME THING. *Lamins* structure the *nuclear lamina*. *Laminins* are the primary component of *basal lamina*, which is a layer of mixed proteins and glycoproteins (proteins with sugars attached) and polysaccharide (sugars linked in long chains) that coat the surface of animal cells and form the basal layer of most connective tissue. Also, today I learned about the basal lamina. I'm sure I've encountered it in some bio class along the way, but I never really got what it was, and how it differs from any other extracellular matrix. In short, the extracellular matrix is bulky, where the basal lamina is sheet-like and typically sticks directly to a layer of cells. They're also made from different proteins, but I don't understand the consequences of those differences yet.

Wednesday, September 6, 2017

September 06, 2017 at 10:07PM

Today I learned: 1) On macs, there's a keyboard shortcut that lets you add umlauts to vowels. Today I learned that it can also be used to make a naked umlaut: ¨. The same thing works for some other accents, like ´ and ˆ (not ^). 2) ...how hurricanes work! At least, a little bit. A hurricane is basically a giant, roughly-donut-shaped cell of moving air. It gets started when there's a lot of hot water. Like, a LOT of hot water. Heat from the water heats the air above it, and moistens it by evaporation. That air rises and cools, eventually forcing out the water vapor as clouds. That part above describes quite a few types of cloud formation. What makes hurricanes happen is that oceans are HUGE and contain a LOT of heat, so it takes a LOT of air to carry away all the excess. So much air get heated and forced upwards, in fact, that the air pressure lowers, which draws in air from the surrounding ocean. Then *that* air gets heated and rises, etc. If this happens forcefully enough, for long enough, it forms a cell, where air circulates up, out from the center, down, and back in toward the center. All the while, it's sucking water up into the accumulating cloud layer, which eventually gets dumped out when the whole thing hits something that isn't warm water (usually land). Why do hurricanes spin? Uh, something about coriolis forces, I'm sure. 3) There's a really cool unit-testing package for Python called Hypothesis that lets you test functions by defining guarantees of those functions, like "this function doesn't throw an error" or "this function *does* throw an error" or "if you serialize and read back a value using these functions, you get the same value back". Hypothesis automatically generates test cases from your specifications, paying particular attention to edge cases of various kinds. When you run your unit test, it runs all of the Hypothesis-generated test cases. If there's an error, Hypothesis will try to find the simplest possible example that breaks your specs and tells you what that example was. Honestly, this package sounds a little too good to be true to me -- anybody out there have experience with it? Lady Jade?

Sunday, September 3, 2017

September 03, 2017 at 10:50PM

Today I learned: 1) ...that I don't understand magnets. At all. What I am quite sure of is that magnetic fields are generated by moving electric charges. So when electricity flows, it generates a magnetic field. So far so good. But then what the hell is a static magnet? There's no charge flow in a refrigerator magnet! It turns out that I am right to be confused. There's a theorem from the late 1910s called the Bohr-van Leeuwen theorem (what awkward punctuation! Surely English can do better than that?) that says that when you apply statistical mechanics to a classical system of particles with charges and mass and all that, the net magnetization is *always* zero. In other words, classical physics *cannot* explain static magnets. So... what does? You guessed it -- quantum mechanics. For one reason or another, in QM, electrons end up generating a tiny little magnetic field around themselves. If you line up all the little magnetic fields, you get a big magnetic field. Why do electrons generate magnetic fields? Spin mumble mumble I have no idea. Now, the Bohr-van Leeuwen theorem only applies to non-rotating systems, so it's possible that classical mechanics can still explain, for example, the magnetic fields of stars and planets. But I can neither confirm nor deny whether it actually does. 2) Something else I don't understand -- and I'm throwing this out there to see if anyone does understand this -- what drives the colossal storms on Jupiter and other gas giants (but mostly Jupiter)? On Earth, hurricanes and typhoons are powered by warm water, which is itself driven by sunlight. But Jupiter is much farther than Earth from the sun, and it has much more powerful storms. Where does the energy come from? 3) Ledo Pizza now has a vegan pre-built pizza. It's easy enough to make one anyway, but theirs is better than any I've built.

Saturday, September 2, 2017

September 02, 2017 at 09:24PM

Today I learned: 1) I'm a big fan of the Chipotle* system of food service. For those not in The Know, I'm talking about restaurants where you build a food from a bar of ingredients, and then get it cooked super-quickly. One cool thing about the system is that it works for a lot of different foods: Chipotle makes burritos; Subway makes sandwiches; Blaze makes pizzas; any number of Mongolian barbeques make... some sort of unholy American seared-noodle thing. So... what food *hasn't* been made with the Chipotle system that should be? Until today, my answer was "pasta" (and no, Mongolian barbeque doesn't count). Today I learned that there's a restaurant called Noodles and Company that's basically the Chipotle of pastas. It's not *exactly* the same model, because they don't have the bar of toppings to choose from explicitly. It's more that they have a bunch of pre-arranged selections of pastas that you can customize heavily. Still, it's close enough to the Chipotle system that I'm counting it. *Really it's the Subway system, but I'll eat Chipotle over Subway any day, so for the purposes of this series of posts, it's the Chiptle system. 2) ...how the sliding doors work in the Ikea PAX system of wardrobes. It's pretty simple, all in all, but there are a lot of ways you can misassemble it. In particular, there are two rails on the top and two rails on the bottom, one for each of two sliding doors. If you hang either end of either door onto the wrong rail of either the top or bottom, you get some nasty physical conflicts. Also, importantly, the screws on the PAX doors tend to come loose over time. If you have a PAX wardrobe, make sure to check the screws on the back of the doors every couple months. If a screw loosens too much on the outer door, it can get the whole door stuck so that the doors can't come apart, leaving you with a one-door PAX wardrobe. 3) Early computers used to break a lot. For some reason, discrete components (transistors, resistors, capacitors) are a lot more failure-prone than integrated circuits (anybody know why?), so computers built out of discrete components (all of the early ones) were a lot more breakage-prone. Accordingly, debugging used to be a lot of tracing out circuit diagrams and figuring out what components would produce the bug if broken. I count this as a "fact" particularly because it's really antithetical to all of my programming instincts -- in my experience, if you run into a bug, it's because you made a mistake. No, the interpreter is not mis-reading your bytecode. No, your compiler doesn't have a bug. No, your processor *definitely* isn't broken (unless it's a Pentium P5 800 nm 5V or a Pentium P54C 600 nm 3.3V -- http://ift.tt/1LvPh8u). You made a mistake, and you have to find and fix it. But that wasn't always true. #todayilearnedToday I learned: 1) I'm a big fan of the Chipotle* system of food service. For those not in The Know, I'm talking about restaurants where you build a food from a bar of ingredients, and then get it cooked super-quickly. One cool thing about the system is that it works for a lot of different foods: Chipotle makes burritos; Subway makes sandwiches; Blaze makes pizzas; any number of Mongolian barbeques make... some sort of unholy American seared-noodle thing. So... what food *hasn't* been made with the Chipotle system that should be? Until today, my answer was "pasta" (and no, Mongolian barbeque doesn't count). Today I learned that there's a restaurant called Noodles and Company that's basically the Chipotle of pastas. It's not *exactly* the same model, because they don't have the bar of toppings to choose from explicitly. It's more that they have a bunch of pre-arranged selections of pastas that you can customize heavily. Still, it's close enough to the Chipotle system that I'm counting it. *Really it's the Subway system, but I'll eat Chipotle over Subway any day, so for the purposes of this series of posts, it's the Chiptle system. 2) ...how the sliding doors work in the Ikea PAX system of wardrobes. It's pretty simple, all in all, but there are a lot of ways you can misassemble it. In particular, there are two rails on the top and two rails on the bottom, one for each of two sliding doors. If you hang either end of either door onto the wrong rail of either the top or bottom, you get some nasty physical conflicts. Also, importantly, the screws on the PAX doors tend to come loose over time. If you have a PAX wardrobe, make sure to check the screws on the back of the doors every couple months. If a screw loosens too much on the outer door, it can get the whole door stuck so that the doors can't come apart, leaving you with a one-door PAX wardrobe. 3) Early computers used to break a lot. For some reason, discrete components (transistors, resistors, capacitors) are a lot more failure-prone than integrated circuits (anybody know why?), so computers built out of discrete components (all of the early ones) were a lot more breakage-prone. Accordingly, debugging used to be a lot of tracing out circuit diagrams and figuring out what components would produce the bug if broken. I count this as a "fact" particularly because it's really antithetical to all of my programming instincts -- in my experience, if you run into a bug, it's because you made a mistake. No, the interpreter is not mis-reading your bytecode. No, your compiler doesn't have a bug. No, your processor *definitely* isn't broken (unless it's a Pentium P5 800 nm 5V or a Pentium P54C 600 nm 3.3V -- http://ift.tt/1LvPh8u). You made a mistake, and you have to find and fix it. But that wasn't always true.