I was happily running ArchLinux for a while, but something went wrong with the xorg install so I had to switch. It took a while to get the disk encryption and UI setup correctly on Arch and I didn’t feel like going through that again so I didn’t want to re-install that. And I hate Unity, so Ubuntu was out.
I decided to give Fedora a try. Fedora figured out my disk encryption and was an incredibly easy install. It worked fine for a couple weeks, but then I realized I hadn’t updated any of my packages yet, so I tried that. And bricked my laptop. Turns out that while a 100MB /boot partition is just fine for ArchLinux, but is way too small for Fedora and the kernel update filled the partition.
My choices are now:
- Keep Fedora and figure out how to change LVM partition sizes without destroying my encrypted /home
- Keep Fedora and wipe out my existing /home partition
- Switch to something that can handle a 100MB
Documentation for resizing LVM partitions makes it look hard. My /home partition is backed up, but it’s a hassle to restore. Plus I’m kind of annoyed that Fedora refuses to work with 100MB /boot partition. So on to option #3.
Manjaro Linux is based off of Arch but has a better UI setup. This sounded good. And it comes with Steam preinstalled; even better. Unfortunately the installer couldn’t figure out my encryption the way that Fedora could.. I emailed one of the maintainers about the experience and decided to move on.
Next up? Mageia Linux. Once again I hit snags with figuring out the encryption. Now what? openSuse? Also reconsidering wiping the disk and restoring from backups just so I can get back to work. I’ve got a couple of replies from one of the Manjaro maintainers and it does seem like a fun way to go. Let me give that one more try.
I’ve spent all morning, but I finally got it to boot. The encrypted disk installation is clearly not a fully implemented feature but with the help of the Arch docs I was able to get it working.
Here are a few changes I had to make to /etc/mkinitcpio.conf
- Add ext4 to MODULES
- Add encrypt and lvm2 to HOOKS
- remove fsck from HOOKS; mkinitcpio was complaining about there being no fsck.auto when I tried to run it
And fixes to the “append” line in /boot/syslinux/syslinux.cfg:
- Fix root to be “root=/dev/mapper/pv1-lv2” where pv1 is the physical volume and/or volume group and lv2 is the logical volume for the root partition (/)
- Add “cryptdevice=/dev/sda2:pv1” where pv1 is the name of the volume group and/or physical volume
I haven’t used it much yet, but after getting it all to work I have a much better understanding of how it all works and it should be easier if I ever have to do it again. Hopefully I’ll still think it was worth it after a few months of use.
I got 99 problems getting my daughter interested in tech but 3 people I don’t know at PyCon isn’t one.
There was a debacle at PyCon last week that’s received a lot of commentary, but that’s not the reason that STEM jobs are overwhelmingly held by men. It’s not like PyCon was gender balanced before this year and this incident chased all the women out of the industry. Here are a few pre-existing conditions that are pushing women away from STEM before they even choose a field of study.
- 5 main characters in the Big Bang Theory: the only female is the only non-scientist
- Girl children expected to be bad at math
- Disney princesses
- US immigration policy keeps many educated women from working in the US
- Too few female role models
- Lack of publicity for female role models
- Every product for girls is pink
- Video game industry that primarily targets boys
- Only one female star in the movie Hackers: Angelina Jolie
- Professor Farnsworth
- Two Broke Girls
- Mad scientists are almost always men
- xkcd shows how it works
- Forever 21
- Photographs of Albert Einstein
The Federation is facing some cutbacks…
I had a bit of a milestone today in the programming language I’ve been writing. It now supports simple pattern matching and recursive function calls, which are useful for implementing the factorial function. Here’s what the code looks like:
factorial := ?(1) => 1 ?(0) => 0 ?(n) => n * factorial(n-1) main() => write(@stdout, msg) where result <- factorial(5) msg <- "factorial(5) is $result\n"
factorial() is defined as a pattern matching function that takes 1 parameter. main() returns the result of write(@stdout, msg). result is assigned the value of factorial(5) and msg is assigned a string with the value of result inserted in place of “$result” in the string.
The language is broken down into 3 parts:
- A front end compiler that translates the language shown above into a virtual machine assembly language.
- An assembler that translates the assembly code into a virtual machine bytecode.
- A bytecode interpreter that executes the assembled program.
Besides declarative style pattern matching, the front end language is meant to support closures, multimethod polymorphic dispatch and a few other goodies (hint: better error handling).
The assembly language is designed to be independent and standalone so that any other front end language (such as a template language) can generate bytecode for the interpreter. See the generated assembly code for the function above.
The bytecode interpreter supports inline asynchronous I/O (no coding with callbacks) and eventually, Erlang style concurrency.
All this will go on github at some point, but I’m trying to realize a few more of these goals before making it public.
Joel Spolsky influentially wrote that every interview should conclude with a Hire or No Hire decision. From the company’s perspective, this is true. But there are additional questions too:
- What if two people disagree on the Hire/No Hire question?
- How willing should you be to get into a bidding war if the candidate has other offers?
To address these questions, I’d like to introduce the following grading scale. Each interviewer gives the candidate one of the following grades based on their own interview.
A: Hire, and wants to make a case if others disagree
B: Hire, but won’t argue if others disagree
C: No Hire, but willing to yield if others feel strongly about hiring
F: No Hire, and will argue if anyone thinks Hire
Now when compiling the results, it’s easier to see when a dissenting opinion can be overridden or when it’s necessary to act fast and make a convincing offer. Consider the following example where 4 people interview one candidate:
In this case 2 people feel strongly that the candidate should be hired, and one is mildly No Hire. This interviewer may not have had a great read on the candidate or may have interviewed for a lower priority skill for the job and it’s still appropriate to hire.
This strategy can also be applied generally to any case where a group of people are making a yes/no decision. It’s transmission of 2 bits of information instead of just 1. The first bit is the individual saying yes or no. The second bit is what the individual will do if the group disagrees. The individual is sending information not only about the present, but also about a potential future situation.
Let’s assume for the sake of this post, that you accept the fact that MVC as a web pattern is well past its due date. What then can replace it? The answer, of course, is VADDR. Don’t worry, it’s not at all related to any Sith Lords you may have heard about.
The primary goals VADDR wants you to achieve are security and testability. Rather than being defined by how the functions and code are arranged, VADDR is defined by the phases that data passes through while processing a web request. Once the phases of data are known, how to arrange the transitions between phases becomes obvious.
These are the 4 data phases in the VADDR pattern:
- VA - Validated/Authenticated Input
- D - Database Records
- D - Domain Objects
- R - Render Objects
That MVC has nothing to say about input validation is reason enough to disregard it as a design pattern relevant to the web.
With VADDR, there is one object per request for Validated and Authenticated Input. Doing the work to create it is the first step in processing a request.
Any URL or POST params and even cookies must be validated first. Upon validation, they are used to create an object that is typed specifically for each request. Subsequent transitions only have access to this object. If it’s all just validated input, it allows the application code and tests to disregard the complexities of the HTTP context.
Also, the validation phase is where the current user’s session and CSRF token should be verified. Any failures to generate this object should cause the app to stop and send a 4xx error. By generating the Validated/Authenticated Input as the first phase of data, each request reminds the developer about the primary goal of security.
This bit is most similar to the M in MVC. They are objects that model exactly what lives in the database. The “database” can be an RDBMS, a NoSQL document store or even a local or remote REST endpoint. The point is, this type of object represents what comes from the data source, before any processing or logic is applied to it.
While I/O is necessary to fetch Database Records or write them to persistent storage, transitions between Database Records, Domain Objects and Render Objects should be pure. This helps make the most important parts of the program easily testable, another of a developer’s primary goals.
In MVC, Database Records, Domain Objects and Render Objects are often merged into a single type. When the single object doesn’t exactly fit it’s application, code complexity ensues. If they are broken up, it’s usually in an ad-hoc fashion that varies from one component to the next even within the same application.
With VADDR, Domain Objects are a distinctly separate idea. Domain Objects represent the domain model of the application regardless of how things are normalized and structured in the database. For example, a Domain Object may aggregate some data from a parent record into a child record as a single object.
The final phase is for passing data to templates, json or other output code. These objects should model the display layout to make front end rendering faster and less complex.
One example might be a HeaderRenderObject. It includes the user’s real name, counts of new messages and any other relevant info meant to be displayed in the header. User info not displayed in the header is excluded from this object as it’s targeted specifically for this case.
In some cases of VADDR, especially for small and/or new apps, there may be no differences between a database record, a domain object and a render object. In this case, there is simply no transformation necessary, but it’s still useful to think about there being 3 applications for that one object. If and when the domain or display start to drift, VADDR expects a new type to be created for the necessary phase, so that the data stays tuned specifically for its purpose. The key to simple code is appropriately structured data.
VADDR: A New Hope
As a pattern, VADDR aims to provide specific guidance on how to phase data so that programs are easier to write securely and maintain with testing. And once the data is phased, designs for simple, testable transformation functions should readily revealed themselves. If this sounds good, give it a try. If not, how would you lay out the phases of data? Write it up, or even better, code it up and post what you come up with.
I tried and failed to use real life to buy a dishwasher yesterday. Started at Sears and found a salesman uninformed about their limited selection. Moved on to Home Depot and found a salesman misinformed about their even more limited selection. Once again I turned to the internet for its ability to aggregate data from disparate sources and found success at AJ Madison. Despite selling old school technology like dishwashers and refrigerators, AJ Madison has the best e-commerce site I’ve used for comparison shopping. Only NewEgg is comparable.
Ever tried to put base64 in a URL? You can’t (w/o special encoding) because whatever genius came up w/ base64 (which admittedly is pretty clever) thought it would be fun to make the slash part of the encoded format. Wait, what? Yes, that’s right. The directory delimiter is part of the format. I’m guessing the inventor of Base64 was an MS-DOS user.
But, fear not. Some observant fellow over at Yahoo! also noticed this and came up with Y64. It’s a variant of Base64 that replaces the 3 URL-unsafe characters in base64 (‘+’,’/’,’=’) with URL-friendly characters like ‘.’, ‘_’ and ‘-‘.
Now you can convert to Y64, toss it into a URL and happily watch it work w/o having to do any silly URL-encoding.
Facebook’s new Timeline feature is designed basically to record all human events. Presumably forever. Because otherwise Facebook would get boring. It did get me thinking though. How long before the physical space required by the storage devices recording all human events actually surpasses the physical space required by presently occurring events? Probably later than decades and sooner than milleniums, so let’s say it will happen in centuries.
This brings me to my point: datacenters in SPACE! Sure, you’re skeptical, but what do datacenters need? Plenty of electricity, bandwidth and room, and a dry, cold environment.
The sun’s up there, so we’ve got solar powered electricity covered. Bandwidth is the reason most of our satellites are already up there, so we know we can do that. Of course there’s plenty of room. They don’t call it SPACE for nothing! And, if you haven’t been to space, I can assure you, air conditioning in space will not be necessary (which further reduces our electricity needs). In fact, space is cold enough that superconductor based chips would be as easy to operate as normal chips so our programs would be absolutely flying!
Given the look on your face, I can see you’re still not convinced. That’s ok. Eventually, when datacenters are as prevalent as suburban strip malls, you’ll come around. And it will be that much handier to travel in space once our websites are already running up there.