I thought about using Dropbox as a location for a repo. It doesn't take much thought to realize why this isn't safe.
If you push to a shared Dropbox based repo, Dropbox will detect the changes and begin syncing everyone else's copy. If someone else tries to read at that moment, they will get an inconsistent view, and if they try to do a commit or push themselves you are likely to see corruption as Dropbox and Git's writes clobber one another.
Clobbering repos is bad. Don't do that. Use GitHub instead, or a virtual server running something such as Gitolite and GitLab.
Saturday, March 17, 2012
Wednesday, March 14, 2012
HTML5 is simpler than possible
See anything wrong with this line of code?
Neither did I. But after copying up a minor style change to my company site, this little line botched up the appearance of the whole site.
The company site was suddenly raw and styleless, as if a developer tools add-in had disabled all styles.
A previous post here, CSS Grammar Considered Wrong remarked upon the muddy expressiveness of the syntax. As an expression of a solution the syntax lacks Focal Alignment. HTML is in a similar condition, and HTML5 especially.
Take another look at the quote character in the HTML:
Yep, that's a completely different quote character, not the usual double-quote. HTML5's new parsing rules state that we can omit quotes around contiguous attribute values. So when the errant quote character is used, the actual resource that the browser attempts to download is:
That is, the not-really-double-quote characters are silently taken as part of the attribute value.
HTML5 browsers are not supposed to complain or flag errors, just gobble up characters and do something predictable. That's what makes HTML5's parsing a simpler solution than possible.
<link rel=”stylesheet” href=”stylesheets/agilemarkup.css” />
Neither did I. But after copying up a minor style change to my company site, this little line botched up the appearance of the whole site.
The company site was suddenly raw and styleless, as if a developer tools add-in had disabled all styles.
A previous post here, CSS Grammar Considered Wrong remarked upon the muddy expressiveness of the syntax. As an expression of a solution the syntax lacks Focal Alignment. HTML is in a similar condition, and HTML5 especially.
Take another look at the quote character in the HTML:
href=”stylesheets/agilemarkup.css”
Yep, that's a completely different quote character, not the usual double-quote. HTML5's new parsing rules state that we can omit quotes around contiguous attribute values. So when the errant quote character is used, the actual resource that the browser attempts to download is:
”stylesheets/agilemarkup.css”
That is, the not-really-double-quote characters are silently taken as part of the attribute value.
HTML5 browsers are not supposed to complain or flag errors, just gobble up characters and do something predictable. That's what makes HTML5's parsing a simpler solution than possible.
Friday, March 9, 2012
Checkie, part 0
Checkie is a little checklist tool I'm working on to help me remember things. Specifically, it's those things that I get very little reward out of doing, get sidetracked on due to other work demands, and don't do frequently enough to be highly productive especially when procedures or resources change. Basically, things like government reports, reconciliations, and tax deposits.
 |
| courtesy OpenClipart.org, author: jetxeee |
What?
We all have access to on-line bill paying systems. Checkie isn't that. You still have to pay your bills. Checkie will remind you that things are due, where "things" may or may not be bills. Checkie will also provide a place to audit who/what/when/how and whether the obligations you have to meet, were in fact met.
Why?
Anything your really dislike is really easy to lose track of and I really despise paperwork, especially when it is for government. But when I lose track, I have to do even more paperwork, and whether it is an individual or the government losing track of paperwork, the bureaucracy invariably points the finger at individuals and threatens to do them harm. So it is an excruciating pain point. Checkie is my response.
Tools like QuickBooks are supposed to automate this stuff. They fall flat. I'm a programmer full time, and only a book-keeper a small fraction of the time, so the tools require periodic review and can mislead you about what is due, and when. Such tools also don't provide a comprehensive and straightforward checklist that includes state and local filings, or records of whether and when such filings were completed. They're not completely garbage for what they do, they just don't do that.
Perhaps Checkie will also help kids remember chores, or be a back-end for a mobile interface to keep Alzheimers' patients aware of the details, but whether anyone else will care but me remains to be seen. That's why I put up this page.
Perhaps Checkie will also help kids remember chores, or be a back-end for a mobile interface to keep Alzheimers' patients aware of the details, but whether anyone else will care but me remains to be seen. That's why I put up this page.
When?
Um, whenever. I'm just sketching out the design and starting BDD this week and next. I hope to get a crude preview up in a week or two after, schedule permitting. It is early March as I write this.
Where?
Early prerelease versions of Checkie will likely be available through Checkie.AgileMarkup.net, and hosted on the cloud.
How?
Can you get in on Checkie? I can notify you of its availability: just send me a note to let me know you are interested. I promise not to spam you or otherwise use the contact information for unrelated marketing activities, which personally I find abhorrent.
Git Tagging
So, I'm setting up a GIT rep to track my company accounting files. Why? Quickbooks. The files are a moral hazard when, say, the software clobbers the data file, or an update goes awry, or you need to take a snapshot and then the software forgets which one was open. It can get really ugly. GIT ensures that only one file name need ever be present by doing the snap-shooting for you.
I know it is a lot of trouble, but there are two reasons that motivated me to do this: using file-name mangling is a wholly inadequate means of implementing revision control, and keeping the files locked down on one computer or on one network is risky and disruptive to getting things done when you move around to different machines. Under GIT, I fetch my accounting repo, make changes, commit and push the commit back to the remote. If I know I'm going to be moving around to another machine, I can clone into a Dropbox or other network folder and after I commit I can feel secure in removing the clone.
Of course, GIT won't version the Quickbooks file itself in any meaningful way. You can't for instance go back to a previous commit, branch it, and start applying journal debits and credits as corrections, and then merge back into the main line. Just won't work, because a QuickBooks data file is an opaque indexed binary structure, not a line-structured source file.
But we can avoid mangling the file name for snapshot purposes. Yet if we don't mangle names, how will we know which commit is which without relying upon the comments? The answer lies in GIT tagging.
There are two types of tags in GIT, and either would work for this purpose.
The first is lightweight tagging. A lightweight tag is one without other metadata -- things like the tag creator, the date of tagging, and a GPG signature. If all you care about is finding a particular commit given a label, then this is what you'll want:
The only thing this does is point the tag to the current commit.
The second kind of tag is an annotated tag. Here, you tell GIT to make an object with the metadata, and/or a signature:
We can list tags with:
and show the metadata for a tag with:
If you really want to go hog wild, you can apply a digital signature, and verify it. We're really only making read-only snapshots, and adding signing would be a good property for internal data auditing.
More info on tagging at github.
I know it is a lot of trouble, but there are two reasons that motivated me to do this: using file-name mangling is a wholly inadequate means of implementing revision control, and keeping the files locked down on one computer or on one network is risky and disruptive to getting things done when you move around to different machines. Under GIT, I fetch my accounting repo, make changes, commit and push the commit back to the remote. If I know I'm going to be moving around to another machine, I can clone into a Dropbox or other network folder and after I commit I can feel secure in removing the clone.
Of course, GIT won't version the Quickbooks file itself in any meaningful way. You can't for instance go back to a previous commit, branch it, and start applying journal debits and credits as corrections, and then merge back into the main line. Just won't work, because a QuickBooks data file is an opaque indexed binary structure, not a line-structured source file.
But we can avoid mangling the file name for snapshot purposes. Yet if we don't mangle names, how will we know which commit is which without relying upon the comments? The answer lies in GIT tagging.
<TAG>
you're it
There are two types of tags in GIT, and either would work for this purpose.
The first is lightweight tagging. A lightweight tag is one without other metadata -- things like the tag creator, the date of tagging, and a GPG signature. If all you care about is finding a particular commit given a label, then this is what you'll want:
git tag FiscalYear2011-Final
The only thing this does is point the tag to the current commit.
The second kind of tag is an annotated tag. Here, you tell GIT to make an object with the metadata, and/or a signature:
git tag -a FiscalYear2012-Start -m 'Beginning use of GIT'We can list tags with:
git tag
and show the metadata for a tag with:
git show FiscalYear2012-Start
If you really want to go hog wild, you can apply a digital signature, and verify it. We're really only making read-only snapshots, and adding signing would be a good property for internal data auditing.
More info on tagging at github.
Wednesday, March 7, 2012
Inaccuracies at LiveStrong.com
Read this article on LiveStrong.com, and see if you can spot the technical inaccuracy with serious medical consequences for anyone taking it seriously:
As the article states, fructose is indeed "absorbed by cells" without insulin. But only by liver cells, not all cells as the uninformed reader would easily infer from the article. The resulting hepatotoxicity is a driver of fatty liver disease, obesity, and diabetes. By omission the article misrepresents the metabolism of fructose and supports the dangerous myth that glucose is "bad" and fructose is "good".
See <http://en.wikipedia.org/wiki/Aldolase_B#Pathology> for the etiology of the disease mechanism. Overconsumption of fructose sets up an artificial relative shortage of of Aldolase_B.
Comparison Of Sucrose, Glucose & Fructose. Sucrose, glucose and fructose are all kinds of sugar. As you might expect, they all taste sweet -- though to varying degrees.
As the article states, fructose is indeed "absorbed by cells" without insulin. But only by liver cells, not all cells as the uninformed reader would easily infer from the article. The resulting hepatotoxicity is a driver of fatty liver disease, obesity, and diabetes. By omission the article misrepresents the metabolism of fructose and supports the dangerous myth that glucose is "bad" and fructose is "good".
See <http://en.wikipedia.org/wiki/Aldolase_B#Pathology> for the etiology of the disease mechanism. Overconsumption of fructose sets up an artificial relative shortage of of Aldolase_B.
And if you think this doesn't apply to you, think again: given the current formulations of industrialized synth-food and predominance of fructose in popular fruits and vegetables, most of us are chronic fructose-aholics.
Tuesday, March 6, 2012
The terrible iTunes Connect Application process
First, one needs an iTunes content provider account. If you already have one, and used it for publishing apps, you'll need a new one just to apply for iBooks.
Second, one needs to have a paid iBooks publishing account to sell iBooks.
Alternatively, one needs to have a free iBooks publishing account to give away iBooks.
You sign up here.
Apparently, it isn't in Apple's imagination to give free iBooks and sell others under the same account name. Perhaps it simplifies things for someone in the process, or keeps the legalese straight. You can start free but if you want to sell you will need to apply for a new account. The two don't mix.
An aggregator can help ease the process of raw conversion to ePub format:
http://www.smashwords.com/about/how_to_publish_ipad_ebooks
Other aggregators are listed here.
Bear in mind it is unlikely to be suitable for publishing unless the content was originally designed for the iPad.
Even if you get your content into ePub, you still need to validate it.
http://threepress.org/document/epub-validate
is one way to do so.
I resell the oXygen XML Editor, which is a little more robust way of getting into the ePub format and validating it. Since ePub is XHTML based, one can target an ePub for creation via a transformation process that performs composition on components. That is, you don't need to write chapters linearly, but can use topical chunks instead. This can have application to Teachers' Notes, Homework, Solved Problems, Problems to Solve, Quizzes and Tests, and other areas.
Importantly for solved problems, problems to solve, quizzes and tests, generic markup allows the materials to be parameterized. If one knows how the parameters of the problem relate to one another, one can provide a means of customizing materials by varying one or more parameters while also providing a level of sanity checking and guidance to the instructor via information contained in the markup.
For instance, probabilities are usually expressed as a decimal number between 0 and 1; this range could be specified as a limit of a parameter. Or suppose parameter B depends upon parameter A, in that any A in (0,1) maps to some particular B in (2,20). Such relations can be expressed in markup and enacted on a device via a host language, for instance, EcmaScript, via browser/cloud-based customization Web tools, or by a more traditional desktop application.
The question arises: how do we then get these customized ePubs distributed???
Apple's official process, if you can call it a process, is by way of iTunes. But for my trouble of applying over a month ago I have received neither a confirmation nor any other communication about the application's status. Apple's approach to communication is quite opaque.
Checking just now, it looks like they've either changed my password or deleted my original account, because I cannot log in... I do a password reset and change it back to what 1Password said it should be... and it says:
Apple ID does not have permission to access iTunes Connect.
Second, one needs to have a paid iBooks publishing account to sell iBooks.
Alternatively, one needs to have a free iBooks publishing account to give away iBooks.
You sign up here.
Apparently, it isn't in Apple's imagination to give free iBooks and sell others under the same account name. Perhaps it simplifies things for someone in the process, or keeps the legalese straight. You can start free but if you want to sell you will need to apply for a new account. The two don't mix.
An aggregator can help ease the process of raw conversion to ePub format:
http://www.smashwords.com/about/how_to_publish_ipad_ebooks
Other aggregators are listed here.
Bear in mind it is unlikely to be suitable for publishing unless the content was originally designed for the iPad.
Even if you get your content into ePub, you still need to validate it.
http://threepress.org/document/epub-validate
is one way to do so.
I resell the oXygen XML Editor, which is a little more robust way of getting into the ePub format and validating it. Since ePub is XHTML based, one can target an ePub for creation via a transformation process that performs composition on components. That is, you don't need to write chapters linearly, but can use topical chunks instead. This can have application to Teachers' Notes, Homework, Solved Problems, Problems to Solve, Quizzes and Tests, and other areas.
Importantly for solved problems, problems to solve, quizzes and tests, generic markup allows the materials to be parameterized. If one knows how the parameters of the problem relate to one another, one can provide a means of customizing materials by varying one or more parameters while also providing a level of sanity checking and guidance to the instructor via information contained in the markup.
For instance, probabilities are usually expressed as a decimal number between 0 and 1; this range could be specified as a limit of a parameter. Or suppose parameter B depends upon parameter A, in that any A in (0,1) maps to some particular B in (2,20). Such relations can be expressed in markup and enacted on a device via a host language, for instance, EcmaScript, via browser/cloud-based customization Web tools, or by a more traditional desktop application.
The question arises: how do we then get these customized ePubs distributed???
Apple's official process, if you can call it a process, is by way of iTunes. But for my trouble of applying over a month ago I have received neither a confirmation nor any other communication about the application's status. Apple's approach to communication is quite opaque.
Checking just now, it looks like they've either changed my password or deleted my original account, because I cannot log in... I do a password reset and change it back to what 1Password said it should be... and it says:
Apple ID does not have permission to access iTunes Connect.
ARGHHHHHH!!!!! I know that's the account I used to sign up! 1Password says so too. So I pull a diagnostic trick: run the iTunes Connect account application again. Sure enough:
OK, whatever. I have an application, no way to log in, no way to get appraised of its status, and no reasonable expectation that I'll ever hear from Apple on it since they never bothered to confirm the application. Silence is not a good way to communicate.
The process for apps is a game of ping-pong that takes several days between ball bounces, but at least they give feedback. A month is a little long to wait with nary a word either way. I've never seen a business process so craptastic from an organization renowned for products designed to be easy to use.
So, following a trick on Apple's user discussion forums, I give up on the free iBook publishing account option. It seems more like a honeypot meant to divert non-profit oriented people, than a legitimate application process.
I use an alternate account application to the paid iBook application. Even the paid account application assumes that you've got several eBooks in the waiting, just ready to be published. I put in 0 for all the numbers, since I don't yet even have the tools that I need the account to download. We'll see how long it takes, if it is even accepted and doesn't turn into a black hole like the last application. It is March 6th as I write this.
Update: March 8th I had my paid iBook account approved. So the stats are in: 2 days to get a paid account vs 40+ days to get a free account. Lesson learned: use a credit card, and vendors will pay attention.
The following error(s) occurred:
- The iTunes Store account entered has already applied to distribute content on the iBookstore. To continue with this application, you must enter a different iTunes account.
OK, whatever. I have an application, no way to log in, no way to get appraised of its status, and no reasonable expectation that I'll ever hear from Apple on it since they never bothered to confirm the application. Silence is not a good way to communicate.
The process for apps is a game of ping-pong that takes several days between ball bounces, but at least they give feedback. A month is a little long to wait with nary a word either way. I've never seen a business process so craptastic from an organization renowned for products designed to be easy to use.
So, following a trick on Apple's user discussion forums, I give up on the free iBook publishing account option. It seems more like a honeypot meant to divert non-profit oriented people, than a legitimate application process.
I use an alternate account application to the paid iBook application. Even the paid account application assumes that you've got several eBooks in the waiting, just ready to be published. I put in 0 for all the numbers, since I don't yet even have the tools that I need the account to download. We'll see how long it takes, if it is even accepted and doesn't turn into a black hole like the last application. It is March 6th as I write this.
Update: March 8th I had my paid iBook account approved. So the stats are in: 2 days to get a paid account vs 40+ days to get a free account. Lesson learned: use a credit card, and vendors will pay attention.
Monday, March 5, 2012
Personal Responsibility in Rails
A commenter on this Rails issue on the subject of securing resource access to model attributes posits:
"Rails is all about conventions. Broken by default is not a good convention."
Too true. The issue ping-pongs back and forth, but the core idea here is visibility of mechanisms and application behavior. Hiding implementation details can be too much of a good thing, when people really need to know about the behavioral consequences of their actions.
Subscribe to:
Posts (Atom)