C. Keith Ray

C. Keith Ray is developing software for Sizeography and Upstart Technology. He writes code for multiple platforms and languages, including iOS® and Macintosh®.
Go to Sizeography and Upstart Technology to join our mailing lists and see more about our products. Keith's Résumé (pdf)

Wednesday, April 2, 2014

Links

http://feedly.com/e/-sUatCMU birth of the light-saber


http://feeds.boingboing.net/~r/boingboing/iBag/~3/_6-Tz9H199E/story01.htm Rigged stock-trading? Also see Daily Show interview




http://feedproxy.google.com/~r/failblog/~3/er2CdGTxGdA/8130370560 Snakes in toilets -- we need devices to keep them out -- (kickstarter, anyone?) 








quotes:

"So I went back to Things, a program that’s so simple, it doesn’t have a manual. (It’s also Mac only; sorry.) I had the basics down in under two minutes. You click on the Projects button and give the project a name–You Again, Kitchen, Chores, Car, whatever. Under that you click on the Add button and you get a line in your To List so you can break down the job into small parts: Synopsis, Hang Shelf, Wash Dishes, Call Toyoto, whatever. 

"Then you assign a due date for each To Do. That’s it. It does other things–you can assign tags and add notes, etc.–but it does the one thing I need–generate daily to-do lists–and it does it really well."  

"My first to do lists weren’t broken down into small enough tasks, so I’d look at my list for a day and realized it would take forty hours to do what I’d scheduled in twelve. Back to revising the lists, stretching out the time periods for getting things done, making the tasks smaller. My second to-do lists were much better, until I realized that scheduling sixteen-hour work days wasn’t a good idea, either. I can do that for one or two, even three days, but week after week? No. So I went back in and reassigned due dates again, which is easy to do in the program."


Quote: 

"As the day of our first release planning event grew closer, I noticed that there were some blank faces among my extended leadership team when I referred to various aspects of what we needed to do. My heart sank as I asked the team, “Who has read the book?“. A couple of hands were raised. “Who has finished the book?“. Only one hand (and yes he still works with me!). “Who doesn’t own the book?“. At least four or five hands were sheepishly raised. “OK” I said “Change of plan. We are all going to buy the book. If you cannot afford the book, let me know and I will arrange a book for you. Then we are going to read the book together. We are going to form a book club!” As Deming said, “without theory there is no learning”. 
"For the next 3 months I met with my extended leadership team for an hour a week. Each week one member of the team lead a discussion on a chapter or two. We would discuss the concepts covered, how they might apply to our situation and agreed on the ideas we wanted to implement. Book club was compulsory and if one team member had something more important to do then book club was rescheduled. Shared understating and agreement was paramount if we were going to be successful. 
"Visitors to the EDW Release Train are often shocked when they hear that I called a mandatory weekly meeting to read a book. I am always quick to remind them that no one would hesitate to call a “business” meeting, so why wouldn’t we want to make time for a meeting focused on learning ways to improve our “business”."



Quote 
"If you buy an ebook from anyone other than Amazon, you’re buying an EPUB file. Apple and Google, in particular, have aggressively supported EPUB 3 in their iBooks and Google Play stores. As an ebook author, iBooks and the Google Play reader are a dream come true: I can write the book, style it as I please with modern CSS, and be confident that readers will see the text as I intended. 
"For sales on the Kindle Store, I need to generate a KF8 with kindlegen. I have to painstakingly craft my EPUB files so as not to conflict with the limitations in Amazon’s undocumented subset of EPUB3."

http://feedly.com/k/19JcS1I "quartoOpen source ebook formatter (under development) 


Quote 
"Fear of success, just like fear of failure, can paralyze you. Can you find a way to create an experiment that will allow you to succeed, in one small way? Then, use the results to learn from that experiment? 
"If you have the growth mindset, it’s not about you as a boxed-in person. It’s about you as an experiment. You build your emotional resilience and your experiences to help you along the way."


Monday, March 31, 2014

Link Blogging

http://www.niemanlab.org/2014/03/whats-new-in-digital-and-social-media-research-how-editors-see-the-news-differently-from-readers-and-the-limits-of-filter-bubbles/ “Shares, Pins, and Tweets: News Readership From Daily Papers to Social Media”: From Duke University, published in Journalism Studies. By Marco Toledo Bastos. "Social media users tend to favor hard news over soft news, especially on Twitter." "news items about arts, science, technology, and opinion pieces, which are on average more frequent on social networking sites than on newspapers.“The Structural Virality of Online Diffusion,”  "analyze a billion links [...] shared on Twitter. One of out every 3,000 links produced a “large event,” or a sharing phenomenon that reached 100 additional persons [...] truly viral events (many multiple generations of sharing, several thousand adoptions at least) occurred only about once in a million instances."

http://www.vox.com/charles-kenny/#b03g31t20w14 How is the world getting better? Ezra: When I read some of the American decline literature [...] Charles: I think that we’re running out of "others" in a really positive way. We’re not allowed to discriminate against many people we used to discriminate against and so who are we going to have as the threat? Maybe what we’re left with is China. I hope we discover Martians because China is a really bad other. We really need to be cooperating with China. Treating them as a threat is going to be really counterproductive to our own quality of life.

http://proseand.co.nz/2014/02/17/type-programming-shifting-from-values-to-types/ Type programming: Shifting from values to types by Joe Barnes "I need to understand a lot more about the type system in Scala. So as of this morning, I have decided it is time for me to actually learn type programming in Scala [...] I find that all of the resources out there thrust the reader so quickly into the deeper areas of the pool, that reading them is akin to flailing for my life until the lifeguard rescues me and the only lesson I’ve learned is how to not die while in the pool. In this post, I will gently break us into type programming in the kiddie pool."

Link Blogging

http://feeds.boingboing.net/~r/boingboing/iBag/~3/l6Rl-x22u3c/story01.htm "developers who worked on Ultima Online [...] are creating a game called Shards Online over which players will have enormous control. Players will be able to run their own servers, change the code that the game runs on, and add their own challenges. The internal logic of this is a game set in a multiverse[...]"

http://feeds.boingboing.net/~r/boingboing/iBag/~3/yVN83zKFBA4/story01.htm "re-re-launched Amazing Stories, the very first science fiction magazine, founded 88 years ago by Hugo Gernsback. Through the month of April, they'll publish fiction and features, which will be collected as an ezine at the end of the month."

http://matociquala.tumblr.com/post/81284926274/everythingsbetterwithbisexuals-lucymontero "Mary Bowser, former slave of the Van Lew family, infiltrated [...] the household of Jefferson Davis. Bowser was assumed to be illiterate, and as a black woman was below suspicion. Practically invisible, she was able to listen to conversations between Confederate officials and read sensitive documents, gathering information that she handed over to the Union. (From National Woman’s History Museum Facebook Page)"

funny http://cheezburger.com/8129159936?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+SetPhasersToLol+%28Set+Phasers+To+LoL%29 "It's a Love/Rob Situation..." "He used to rob me three times a week, now I'm lucky if I get it once a month..."


Link Blogging

http://www.neat.io/blog/app-developer-vs-seo.html "[three pages] shared the same common template and content." "these three pages (the most important pages to rank for due to their specificity), were not being ranked very highly on Google. Turns out search engines don't like duplicate content and heavily penalise your site for it" "Links which are in bold are also given more weight so each link to a service page is wrapped in strong tags" "Understanding how search engines crawl pages and how they interpret the semantic structure of your pages was eye-opening."

Two "Magnificent Seven" blogs today:

  1.  http://feeds.boingboing.net/~r/boingboing/iBag/~3/iFXG2dI8ueA/story01.htm "Podcast: Collective Action - the Magnificent Seven anti-troll business-model" "The reason the victims [of patent trolls] don’t get together to fight back is that they don’t know each other and have no way to coordinate among each other. In economists’ jargon, they have a ‘‘collective action problem.’’"
  2.  http://agiletng.org/2014/03/21/the-seven-samurai/ "A pattern language for enterprise agile transformation" "Continuous Assessment: Motivate Agile in terms of bottom line metrics." etc.
http://boingboing.net/2014/03/31/google-maps-spam-problem-pre.html "Google Maps' spam problem presents genuine security issues" "a Microsoft Engineer demonstrated an attack against Google Maps through which he was able to set up fake Secret Service offices in the company's geo-database, complete with fake phone numbers that rang a switch under his control and then were forwarded to real Secret Service offices, allowing him to intercept and record phone-calls made to the Secret Service" "this is a higher-stakes version of a common spam-attack on Google Maps practiced by locksmith, carpet cleaning, and home repair services" "Google’s basically getting a not insignificant amount of their income from scammers—if you look at locksmiths, 99 percent of them are scammers,” says Austin"



Repels the Cable-Chewing Cat

American Terminal SL250-100 1/4-Inch Split Loom Tubing, 100 feet "One of my cats likes to chew on cables -- particularly expensive ones belonging to Apple products. I've used this product to cover many of my cables, starting at least a year ago, and I haven't seen any evidence that my cat has chewed on them. So, I guess they work!"

Getting this tubing over the cables isn't easy, but you only have to do it once (per cable)."

Link Blogging

I am going to post links to "interesting" articles I encounter, with a short quote and/or tiny amount of explanation. Sometimes a short quote or explanation will be too long to tweet, and I don't want to fill my tweet streams with a hundred links per week.

http://letsworkshop.com "Workshop is a daily newsletter and community delivering the best freelance opportunities to your inbox" "100% freelance-friendly leads" 10 leads/day = $64/month 5 leads/day = $99/month

http://www.cheryl-morgan.com/?p=18787 "Origins of Feminist Transphobia" by Cheryl Morgan "Back in the 1970s, being a radical feminist often meant being a lesbian separatist..." "read Suzy McKee Charnas’s Holdfast Chronicles [which goes into lesbian separatism in depth]" "for lesbian separatists the idea of a lesbian trans woman can be even more horrifying, because it leads to thoughts of people who are “really men” stealing their girlfriends."

http://qualitycoding.org/xcode51-code-coverage/ "Code Coverage Fixed for Xcode 5.1" "The Xcode 5.1 update proved to be more exciting than I anticipated. And I mean “exciting” in the sense of “breaking the tools I use.” xctool stopped working, and so did my code coverage scripts." "go get the latest XcodeCoverage to get up & running again on Xcode 5.1. Enjoy"

http://buzzsumo.com/blog/pitch-journalist-tips-techcrunch-ny-times/?utm_source=hootsuite&utm_campaign=hootsuite "How To Pitch to Journalists: Expert Tips From Techcrunch, NYT and more" "I am appalled by how lazy PR people are and completely fed up with the BS they keep sending me."
"Pitching to a journalist isn’t rocket science. Assuming you have a compelling story, make sure you follow these simple tips:
  • Don’t use buzzwords like “disruptive”
  • Don’t write long introduction – cut to the chase.
  • Make sure it’s relevant to the journalist.
  • Make it short and sweet (lean and impactful)
  • Tailor your pitch to each journalist
  • Answer the question: Why does this matter today?"



Wednesday, March 5, 2014

Microblogged on Twitter

By the way, I recently micro-blogged a series of "straw-man" arguments against, and rebuttals for, unit-testing and TDD. Here they are somewhat expanded. Rebuttals are italic. 

I am NOT making up these straw-men arguments. I’ve even heard them from people who should, 14 years after Extreme Programming Explained was published, have some understanding of incremental design and development, who should know both the differences and similarities between TDD and unit testing, and how refactoring fits into both small and big design activities.

1. straw-man: OO means you can't know what modified something's state.

That sounds like a global var bug. Objects can guard their state. Most people could learn a bit more about designing non-mutable classes, but OO doesn’t prevent you from knowing an object’s state.

2. straw-man: Always-passing tests are useless. 

Yes, tautological tests are useless. Don't do that. You learn something when a rarely-failing unit test fails: something unexpected happened! Either some code (or data) has changed and it now violates a test’s description of how that code (or data) is supposed to work, or the programmers forgot to update their tests. If a test that has been passing for 10 months suddenly fails, you know something is wrong. The worser condition is that no problem is detected until 20 months have passed, and you have to trace changes back to 10-month old code to find out what code-change caused the problem.

Tests that fail frequently or seemingly randomly, indicate a “people” problem: members of the team don’t understand the requirements, or requirements keep changing due to activity outside of the team, or coding or testing not done well and better training is needed.

3. straw-man: without testing-hooks in code, you can't do white-box tests.

Try mock objects.

4. straw-man: to test a for-loop, you need as many tests as there are iterations in the loop. 

Heard of boundary testing? See my Testing on the Toilet entry.

5. straw-man: changing code requires changing tests. 

This isn't a big burden if DRY (“Don’t Repeat Yourself”) is applied to both code & tests. (See also “Once and Only Once.)

5. straw-man: you can't have nice OO because TDD tests are "procedural". 

So not having no tests is required for nice OO?

6. straw-man: TDDing classes = bad design, because incrementally designing a class or classes while writing tests can’t be done well.  And, refactoring the structure of the code (to improve the design) is can’t be done, either.

Really? refactoring is supported by TDD-tests. Do well-designed classes pop out of your head fully-formed?

6. straw-man: when implementing features one-at-a-time, user experience is a  mess.

Before BDD, did you design entire UX in one second? It was incremental then, too.

7. straw-man: the object's state-space is big number (like 2**32) so we can't write enough unit tests, so don't even try.

Heard of boundary testing? See my Testing on the Toilet entry.

OTHER issues with Signed SSLVerifySignedServerKeyExchange ("goto fail" bug)

Mike Bland, whom I worked with at Google, teaching and spreading the word on how to write fast unit tests, find code smells and refactor them away, continuous integration, and TDD, has commented on the "goto fail" bug - and wants to direct your attention to other aspects of that code: the copy-paste code duplication that probably created the problem that the lack of unit tests didn't find:

Mike wrote:
I still haven’t found any other articles that suggest, as mine did, that the same block of code cut-and-pasted six times in the same file was a problem, that it was ripe for factoring out, and that the resulting function was straightforward to test in isolation. That’s curious to me; it’s like people got stuck on the one stupid goto fail; line and started drawing conclusions without looking at the surrounding code, seeing the same algorithm copied immediately above it, and suspecting, as I did, that there was a classic code duplication problem which fixing would’ve likely avoided the bug to begin with, test or no.
(Go read his whole blog entry, it is worth it, and lengthy. So much blogging is too short these days.)

He also wrote:

What’s more, if memory serves, Keith even wrote the Testing on the Toilet article that advocated for breaking larger chunks of logic into smaller, more testable functions to avoid having a combinatorial explosion of test inputs—the very concern that Bellovin had mentioned as rendering exhaustive system-level testing infeasible.5


My response to Mike is:

Hi Mike. Yes I did write a Testing on the Toilet article titled "Too Many Tests", which was posted inside Google as well as on the public Google Testing blog. On of the commenters said "Good example of equivalence class partioning."
In the movie Amadeus, the Austrian Emperor criticizes Mozart's music as having “too many notes.” How many tests are “too many” to test one function?

My personal blogging on the "goto fail" issue did just stick to the testable aspect of the code, because many people were saying it could not be tested at the unit level.

I could have also pointed out the need for code review and/or pair programming and the need for refactoring, based on a foundation of well-tested code, but I kept that blog entry focused only on the 'testable' topic.

[PS: Check out the "Real Programmers Write Tests" merchandise on my blog's home page.]

Tuesday, March 4, 2014

Next Product For Sizeography

As CTO and chief programmer of UpstartTechnology and the Sizeography division, I'd like announce our next product, already in progress.

hands holding tape-measure to find size of unknown object


This new app will allow you to place a common object on, or neat, another object, and find the approximate size of the unknown object. For example, if you place a quarter on a small table, snap a picture of it in our app, the app will compute the size of the table.

While the app won’t be ready right away, we want everyone to have a say, so after we get suggestions for the name, we’ll hold a vote to see which of the names wins.

Nominate a name for app in the comments to this blog (or our main company blog), and look for the poll to be put up after we’ve gotten some good suggestions for names. (G-rated names only, please).

How to enter: Leave a comment with your app name suggestion[s] and make sure we have your email so we can contact you if you win. We’ll take the best names and put up a poll, and the winner of the poll will get the prize.

The prize will probably be an Easter-egg hidden in the app, but if you’ve got a prize suggestion, be sure to let us know in the comments (G-rated only, please).


Sunday, February 23, 2014

TDD and Signed SSLVerifySignedServerKeyExchange

Test-driven development (TDD) done consistently throughout a project results in near-100% logic coverage. That's better than just statement coverage. It also results in testable code, better modularity, better design (if you pay attention to code smells), and faster software development.

The heart of TDD is:


  1. Write a test. Running that test should fail. (Tests are often simpler than the code they test, so usually this step is pretty easy.)
  1. Make the test pass by writing just enough code. (All other tests should pass as well.) 
  1. Refactor. (Not done every time through this loop; remove duplicate logic and look for other code smells.)
  1. Repeat until desired feature is implemented. 
  1. NOTE: Checking into source-code-control can be done whenever all tests are passing. (A Continuous Integration (CI) server can also run tests: the "fast tests" created by TDD and slower system tests.)


Badly-designed code is hard to test. Most developers who try to use TDD in a badly-designed, not-unit-tested project will find TDD is hard to do in this environment, and will give up. If they try to do "test-after" (the opposite of TDD's test-first practice), they will also find it hard to do in this environment and give up. And this creates a vicious cycle: untested bad code encourages more untested bad code.

If code is only written to make a test pass (as in TDD), you can't write an if statement until you have a test that requires it. You should end up with a test for the if statement being true, and a test for the if statement being false, possibly more than one test for each branch.

TDD in C is not terribly hard. I've taught people how to TDD in C and other languages. And the suites of tests created by TDD makes it possible to refactor with more confidence.

If one or more TDD tests (and other tests, like system tests) fail, someone broke something. The fine-grain testing that is part of TDD will usually pin-point where the new bug is. Undo the changes that broke the test, or fix things before doing anything else.

(Tests that fail unpredictably indicate something is non-deterministic either in the code-under-test or the test itself. That also needs to be fixed.)

landonf demonstrated that SSLVerifySignedServerKeyExchange() is unit-testable in isolation. See his code on github. I copied his unit test for a bad signature here:

@interface TestableSecurityTests : XCTestCase @end

@implementation TestableSecurityTests {
    SSLContext _ctx;
}

- (void) setUp {
    memset(_ctx.clientRandom, 'A', sizeof(_ctx.clientRandom));
    memset(_ctx.serverRandom, 'B', sizeof(_ctx.serverRandom));
}

- (void) tearDown {
    [super tearDown];
}


/* Verify that a bogus signature does not validate */
- (void) testVerifyRSASignature {
    SSLBuffer signedParams;
    SSLAllocBuffer(&signedParams, 32);
    uint8_t badSignature[128];
   
    memset(badSignature, 0, sizeof(badSignature));
    OSStatus err;
    err = SSLVerifySignedServerKeyExchange(&_ctx, true, signedParams, badSignature, sizeof(badSignature));
    XCTAssertNotEqual(err, 0, @"SSLVerifySignedServerKeyExchange() returned success on a completely bogus signature");
}

@end

Friday, February 14, 2014

A Key Aspect of Successful Projects

Rapid responses to questions is often a key to successful projects. Extreme Programming and other agile methods like Scrum consider this to be so important as to require the domain expert / product manager / business analyst / "product owner" / "Customer" to be co-located with the developers/testers. 

Obviously some projects can be successful without co-location, but odds against success rise whenever developers can't quickly and easily communicate with the Customer.

Tuesday, January 28, 2014