Culture, heritage and apps

I said earlier on Twitter that I’m disappointed with the state of apps produced for museums and libraries. I’d better explain what I mean. Here’s what I said:

Disappointed to find that many museum apps (British Library, Bodleian, Concorde etc) are just the same app with different content. :-(

In each case (particularly Concorde) there’s some magic specific to the subject. Rubber-stamping the app doesn’t capture that magic.

They’re all made with a tool called Toura that sits atop PhoneGap. Makes it easy to get the content into the apps at the cost of expression.

So to be clear: my problem is not with the museums and other heritage sites. I’m familiar with the financial and political problems associated with running a museum. My social circle includes curators, librarians and medieval manuscript experts and I know that money is tight, that oversight is close and that any form of expenditure in promotion must result in a demonstrable increase in feet through the door and donations to be considered a success.


The Magna Carta

My problem is also not with the Toura product and the team behind it. They’re to be commended for identifying that while the culture and heritage community doesn’t have much money, they still deserve to be represented in our tablets and phones. The apps I listed above all feature astounding objects: examples include the Concorde aircraft, the Lindisfarne gospels and the Magna Carta.


Concorde

So why are these apps disappointing? It’s basically because they’re all the same. Each of these objects has its own magic: the unique shape of Concorde, the vivid colours of the gospels and the constitution-defining text of the Carta. So why present them in the same way? Why not make a Concorde app that evokes aerodynamic speed, an illuminated Lindisfarne gospels app, and a revolutionary Magna Carta app? As many people have explained, it’s because standard content-viewing apps like Toura are all these institutions can afford.


Folio 27r from the Lindisfarne Gospels: image from Wikimedia Commons

There’s something seriously wrong in our app industry. We’ve created a world in which apps are too cheap, and developers struggle to make a living from 70¢ per sale. Simultaneously, we’ve created a world in which apps are too expensive: the keepers of some of the world’s most interesting objects can’t afford to showcase these with more than a generic master/detail view. What’s that about?

What mindset leads us to demand high worth, when we’re making products that we can’t convince customers contain any value? If they don’t see the value, are we deluding ourselves? People talk about events like the Instagram acquisition as being evidence of a bubble subset of the app economy. But isn’t that oxymoron – a free app that’s worth a billion dollars – just an exaggerated version of what the rest of the industry is up to?

Let me present this problem in a different way, by moving from apps about museums to museums about apps.

IMG_0114.JPG
The Rijksmuseum, Amsterdam.

Last month I spent an enjoyable time with some very good friends in Amsterdam, the city of both apps and museums. While walking around the Rijksmuseum, I reminded myself that we’re in the middle of the possibly the largest and definitely the fastest technology-mediated social revolution humanity has ever experienced. Those of us enabling the application of this technology are literally providing the fulcrum around which our species is revolving.

During this year, museums will look at apps as cultural, historical and ethnological artefacts in their own right. Over the coming century, heritage institutions will shape the way that our brief period in time is presented for posterity. Be sure that all of the million apps currently available across all app stores will not be on display.

As with any presentation, perfection is achieved not when there is nothing left to add but when there is nothing left to take away. Just as you can’t (and wouldn’t want to) walk into a museum and see every manuscript from the 10th century on display, you won’t be able to walk into the Nieuwerijksmuseum in 3112 and see every app from the 21st century. Only those that are considered cultural treasures will be given pride of place in the galleries. Can something that apparently has no value be considered a cultural treasure? Will any of your apps be part of the presentation? I don’t think I’ve yet produced anything that will be, and that needs to change.

Posted in Business | 2 Comments

Test-Driven iOS Development

Here it is, after more than a year in the making, the book that they really did want you to read! Test-driven IOS Development (Developer’s Library) (affiliate link) has finally hit the stores[*].

I wrote this book for the simple reason that it didn’t exist. Like Professional Cocoa Application Security (Wrox Professional Guides) (another affiliate link), I knew that the topic was something many people were interested in, including myself. I wanted a single place I could go to find out about using Xcode for writing unit tests, and how the Test-Driven Development approach could be applied to writing Cocoa code with Objective-C.

Well, it turned out that this place didn’t exist, so I tried my best to create it. In the book you’ll see how the BrowseOverflow app was built entirely in a test-first fashion, using OCUnit and Xcode 4. Along the way, I hope you’ll see how TDD can be useful for your own projects.

If you’re interested in finding out more about test-driven development for iOS apps, I’ll be giving a talk on the subject at iOSDev UK in Aberystwyth in July. And of course I’m happy to field questions about the book or about TDD here or over on Twitter. And of course my unit testing video training course is still available from iDeveloper.tv.

Happy testing!

[*]The availability appears to vary by country and format, so if it isn’t in your favourite (e)bookstore yet just be patient and keep refreshing that page like it’s the WWDC site.

Posted in books, PCAS, software-engineering, TDD, TDiOSD | 6 Comments

On the magic of key agreement

Imagine that you want to implement AirDrop, or something like it. Two computers that have (possibly) never communicated before are going to share a file. Now you know that you want to encrypt the file in transit so that only these two computers get to see the file, but how do you set up an encryption key? You can’t generate it on one of the computers and send it over, because that way lies the infinite stack of turtles: how do you keep the key secure in transit?

The solution (or at least, one solution known as the Diffie–Hellman protocol) turns out to be beautifully simple. First, arrange that everyone knows two numbers, which we’ll call the base or generator g and the modulus m. For example, in the SKIP protocol these two numbers are documented:

g = 0x cf ca d9 90 8d 98 c1 c4 4e 4e 88 20 69 e8 7b fb
d0 ca e1 ee 24 64 a9 6c 89 70 a0 8c 86 00 30 c6
c2 83 4a 0d 82 bd a5 ba 10 cf 80 af 61 96 11 4b
3b 87 a9 7e 59 98 c4 aa 0c bd b7 2b 23 18 33 64
f3 b6 2e 1a 4d e8 86 85 aa de 78 a1 5d ce 65 33
75 7a 9d 00 b9 9e 05 26 ed 79 62 15 97 c4 06 26
fa 51 e1 5e f5 1d cb d2 23 e2 73 e5 f2 c7 3c c4
de 58 cd 3b b6 15 3c aa 84 7c fa 5f cb 6b 8d 78

m = 0x dd c9 08 3e 8f ae ef 28 16 ad 50 a9 68 ac bd 04
8e 90 9e ab 5d 41 fc 0a 51 3f 86 0a c4 1b 22 b9
30 dc a3 0a 59 73 05 38 59 b7 85 66 df ff c6 5b
b9 1f fe 44 d9 d6 5e cb 9b 68 38 a1 fd 25 3f 01
51 88 9e 93 c3 22 24 f9 03 e6 9b 8b 07 34 9d 9f
9b 38 4b c0 97 03 dc e5 2e 92 47 4c 2c e1 59 26
14 82 49 dd 58 13 91 05 12 11 a1 45 06 ac 11 8f
b1 83 53 46 93 88 9a 46 b1 8a 01 50 cb 5e 82 55

The two computers each generate a random number, which we’ll call x_A and x_B. They keep these numbers secret, but can independently calculate:

r = g^(x_A) mod m

s = g^(x_B) mod m

and they send each other r and s. The first computer can use x_A and s to derive:

k_A = s^(x_A) mod m = g^(x_A.x_B) mod m

while the second uses x_B and r to derive:

k_B = r^(x_B) mod m = g^(x_A.x_B) mod m ≡ k_A

They got the same key! Because you can’t gain any of the secrets k, x_A or x_B knowing only r and/or s, the two systems can negotiate a secret key that’s only known to the two of them without having to first establish a secure channel. I just think that’s really cool.

If you want to use this stuff in an iOS app, OpenSSL contains an implementation of Diffie–Hellman. On Android javax.crypto.KeyAgreement can do it for you.

Posted in Crypto | Comments Off on On the magic of key agreement

On my newer competence

This time last year, I evaluated myself against the programmer competency matrix. So where am I one turn around the daystar later? I have to admit that this was mainly because I was jet lagged in a hotel room in Seattle and had nothing else to do last year :-), but nonetheless it’s time to reflect on how things have gone.

Last year’s goals

I wrote:

it looks like my priorities for research goals over the upcoming year or so should be:

  1. Improve breadth and depth of API knowledge
  2. Investigate systems decomposition of a smartphone/desktop/internet system.
  3. Learn how to create and support DSLs
  4. Write and publish improved developer support tools

So how did that go?

  1. I improved here. I didn’t have a project for doing this, I just used the APIs some more. Things that I previously remembered but needed to look up I now automatically get right, and some things I didn’t know about I now do. There’ll always be room for more.
  2. My work on GNUstep web is only part of this goal.
  3. I haven’t done anything with DSLs, as I haven’t found a need for them in the last year. Maybe that’s because I don’t understand where they can be used :). Part of my GNUstep web project will include rules engines a la Direct 2 Web, so I guess I’ll have to tackle this soon.
  4. Again, in hand with the GSW project. I’ve already published a code generation tool. Some of the things I learned about at NSConference were very inspirational.

What about this year?

I’ll just dive into the matrix. If nothing’s changed from last year you won’t see any comments.

Computer Science

  • Data Structures: still level 1. I’ve learned a little more about level 2 aspects.
  • Algorithms: level 2.
  • Systems programming: level 3, if you’re willing to accept that block-diagram-level knowledge counts as knowledge on the level chart :)

Software Engineering

  • Source Control: level 3.
  • Build Automation: level 3.
  • Automated Testing: level 3.

Programming

  • Problem Decomposition: level 3.
  • Systems Decomposition: level 3. As I said earlier, I made this a specific goal of the last year, and I believe it’s paid off.
  • Communication: level 3. I’ve also done what I set out to do last year, and dialled back on the commitments to conferences and books.
  • Code Organisation Within a File: level 3. As I said last year, this is subjective.
  • Code Organisation Across Files: level 3.
  • Source Tree Organisation: level 3. For these two I’ve decided it’s what you see in the IDE (Xcode, AppCode and Eclipse are my regular haunts) that really matters, though I try to make the filesystem layout match that.
  • Code Readability: level 3. I’m not quite that bastard who rejects code because it doesn’t conform to the standard; though I used to be :-(
  • Defensive Coding: level 2. Still don’t have a “library” for doing that (I’ve written an iOS security library that’s internal to O2, but that’s not what this is about.)
  • Error Handling: level 3 (with s/xception/rror/, because we appreciate that error-handling should be sympathetic to the platform/framework style, just like other code.)
  • IDE: level 3. It was mainly working with AppCode that spurred me into investigating ways to automate IDE functions.
  • API: still going to claim level 1, because I’d say it’s for other people to decide whether they think I have sufficiently “vast and in-depth knowledge”.
  • Frameworks: level 2.
  • Requirements: level 3.
  • Scripting: level 3 (though this improvement only just scraped in this year.)
  • Database: level 1. I’m starting to see more projects where a better knowledge of databases is required, if one of those lands in front of me I’d better improve at knowing databases. However as I said last year it’s the kind of thing where I can use an ORM to get it mostly correct, then investigate whether any issues remain that require deeper inspection.
  • Experience

    I skipped this section last year, but just for kicks I’ll go through it this time. No comparisons with last year, and if you can’t work out why you’re not allowed higher than Level 0 on any entry in the matrix ;-).

    • Languages with Professional Experience: level 2. Functional programming I have worked with includes LISP, C++ and Java (yes, that Java).
    • Platforms with Professional Experience: heh, this depends as I said in a recent talk on how you define “Unix”. Conservatively I could say Unix, Mac, iOS and Java: level 1.
    • Years of Professional Experience: not that I think this matters, but level 2.
    • Domain Knowledge: wait, which domain? In the world of telco (where I currently spend my time) I’m a complete noob. In fact I’ve spent most of my career as a complete noob. Whether that’s good or bad, and something I should or would want to change, is open for debate. Maybe that’s another blog post, later.

    Yeah, having written that section I now understand why I left it out last time.

    Knowledge

    • Tool Knowledge: still level 2. I’ve written and published some codeine scripts, not sure it’s enough to qualify at level 3.
    • Languages Exposed to: still level 2. I did some concurrent programming in Objective-C, but no Erlang, Oz or Prolog. OK, I have done some Prolog tutorials, and Oz is the operating system on my Cambridge Z88 but I’m going to assume that it’s a different Oz.
    • Codebase knowledge: hard to gauge. We have about 100 repos on my team, some I’m not working on, some I collaborate on, some I’m the sole author. We’ll call this one unknowable for now.
    • Knowledge of Upcoming Technologies: level 3.
  • Platform Internals: level 2.
  • Books: still level 1, but I’ve written two now. I don’t imagine writing any more, there must be a better way to share knowledge.
  • Blogs: level 3.
  • This year’s goals

    Some of the things I planned for last year still need to be done:

    1. DSLs
    2. Developer tools

    To which I’ll add some things that, probably, don’t directly follow from the competency matrix, but which are nonetheless goals of mine.

    1. More do, less talk. A side-effect of being “the security guy” in my corner of the industry is that I do a lot of talking about security in other peoples’ products, and not much making products. It’s time to find a product I believe in, and own the crap out of it. That means investing my time in it long-term, not diving in and out like a consultant. Consultants are great and consultancy is great: but I want to build something.
    2. Mentor new developers. A recurring theme from my discussions in Appsterdam and at NSConf is that while I can certainly do a lot to become a better programmer, that won’t scale as well as making a load of other people better programmers. If I can help at least one person become a better developer than I am, I’ll improve my own abilities along the way and then there’ll be two people better than I am.

    That will, I think, do for now.

    Posted in Business, software-engineering | Comments Off on On my newer competence

    An apology and an opportunity

    Today’s earlier post, UX is snake-oil bullshit, was indeed an April Fool. Sorry to the people who had their “WTF blood boil”, among other reactions.

    I’m also sorry to the people I parodied in the post. Please feel comfortable knowing that if I didn’t respect you and what you did, I wouldn’t feel willing to send you up in that fashion.

    Now of course some people saw the joke, and some people didn’t. But what was most interesting was that in both camps there was a (large) fraction of respondents who recognised in the jokes the germ of truth. They realised that the humour came not from eschewing reality completely, but from taking cues from it and dialling them up to 11 so that the absurdity became clear.

    So each of the points in my previous post is true, just not as true as the rhetoric would have you believe. The field of UX does contain people who can spout the platitudes, but don’t back it up. There is an amount of “look at this fail”. It is a fast-moving field, so it’s hard to find timeless, consistent, actionable advice. And there are people who will tell you that whatever they’re doing (or selling) is UX, that when bolted to your product creates magical UX goodness.

    What that means is not, as my April Fool post concluded, that it’s time to withdraw from study of User Experience. It means that there’s a tremendous appetite among software engineers for resources offering specific, actionable tasks that we can undertake to improve the experience of our products.

    One of the books on user experience I’ve got the most out of is Don’t Make Me Think!: A Common Sense Approach to Web Usability by Steve Krug. When he does have some specific issue to point out in the design of a website, he also shows either how the problem was or could be addressed. We could do with a “Don’t make me think!” for the mobile user experience. We need someone to cherry-pick the research on user testing, ethnography and other techniques, telling us what’s important and what to ignore. What we can be doing, and what we should be doing.

    That’s a great opportunity for someone who wants to become the Smartphone UX Boffin.

    Posted in user-error | 1 Comment

    UX is snake-oil bullshit

    There, I said it. I feel better already. There are people in the world who’ll tell you that the most important thing in the world is UX, that if your software isn’t UX-compliant it isn’t worth shit. Here’s why that’s wrong.

    Platitudes

    “Consider the user.” “The user is king.” Yeah? Well why do you name your vaunted “user” after a fucking drug addict? You’re lying, because you know no other life. The user is the poor schmuck that you’re trying to push your apps on, just like a crack dealer. Only of course you don’t call it “crack dealing”, you call it “freemium” and act like it’s some kind of fucking service to let your crackheads – sorry, users – “get familiar” with the product before you start bleeding their wallets.

    Besides, what does it even mean? Consider the user. I looked at my software, and I think users should be grateful that I let them even fucking touch the app store page with their filthy uneducated hands. There, I’ve “considered” the cretins, so I’m doing UX right am I?

    The only examples are bad examples

    Ever seen a UX talk at a software dev conference? I’d be surprised if you haven’t, because these vultures who call themselves “UX consultants” are actually professional speakers who love nothing better than to tell us hard-working developers how we do everything wrong. You’ll be able to spot them if you’re at a conference, they’re the people with the designer jeans and the designer wine glasses and the fucking designer nostril hair. They’ll open their talk with some rant about how the starving children in Africa can wait for help until someone’s fixed the way the fucking tap works in the shower of their six-star hotel room they were in when they gave the same talk in Dubai or some other place us lowlife software engineers can’t afford to visit. You’ll get the impression that we’re the Morlocks, and this fucking Eloi has deigned to come down from the surface to remind us how much better life is up there, and only wants £2000+expenses to do it.

    And then what’s the talk about? It’s a series of examples of what they say is really bad UX, that we’re supposed to sit there and laugh at with them? Fuck that shit. Some colleague of mine has been sitting in a cubicle busting a gut to produce this piece of software, probably with some manager riding their ass and a bunch of conflicting requirements coming from the douchebags in marketing and sales and business analysis and all those other people who don’t know how the fuck a computer works but think their opinions are somehow valid. And this engineer somehow performs the miracle of reconciling all these different inputs, making everybody happy and at the same time writing this gnarly piece of software. You want me to laugh at that? Whoever that is should be given a medal.

    The best bit is of course that these examples are completely worthless. My product doesn’t make people choose which of the fifty states they’re in even when they don’t live in the US. It isn’t some bridge somewhere that projects the cock-signal onto itself at sunset. It isn’t some medical device that kills patients when the nurse forgets to press a button. That means I’m doing better than all the examples, which means I’m doing UX right. Right?

    Capriciousness

    If you manage to get past the fluff talk and the bad examples and trap a UX person into asking what a good example is, you’ll get a different answer every sodding week. Last week they were all telling us how interfaces should be discoverable and how you should have UI elements with clear actions like buttons and things. This week it’s all about these completely arcane and undiscoverable gestures; I mean what the fuck? The last twitter app I downloaded made me page through about ten pages of user manual before it even let me send a fucking tweet, which is the whole point of the piece of crap. You’re supposed to swipe right with three fingers making the shape of the Eye of Horus or some bullshit to retweet, or something like that. The fact is I didn’t read the manual (sorry, “soft landing” as the hipsters want me to call it) so I’ve got no fucking clue how to do even the simplest of things.

    And that’s just this week’s UX hotness. Next week it’ll all be Jordi LaForge visors or some crap, because that went really well for that Virtuality company back in the 1990s.

    Which brings me on to the next way to win at UX without actually doing any work. Build whatever shitty UI you want, and just wait for the UX consultant circlejerk to decide that the way you did it is the way all apps should do it. You’ll only need to wait a fortnight, maybe a month tops.

    Everything – or anything – is UX

    The best thing is that you too can be in on this party! Whatever you know now, whatever you’re an expert in, you can claim is part of the user experience. You know OpenCL? That’s about making things fast and responsive, therefore you’re a UX consultant! You know Core Audio? Making machines go “ping” when something goes wrong is part of the user experience! You’re a project manager? Fuck that, you’re a User Experience Coordinator!

    And so the final way in which I’m winning at UX without really trying is that whatever the fuck it is I do is user experience. Nobody wants to be hacked, right? So security contributes to the….experience…of the…crack addictuser, right?

    Enough of this crap.

    It’s time to acknowledge that UX is a complete load of snake oil, and that its biggest contribution to society has been to reduce unemployment among people who think £150 is a modest amount to pay for a shirt. It’s time to show that us engineers can make software without their help, just as we did both before they came along and indeed while they were swanning around being better than us.

    Therefore I introduce my latest initiative, the Clueless Losers are Inexperienced paradigm for software design. CLI harks back to the days when we knew that computers are tricky and software is hard, and we didn’t apologise for it or pay consultants to apologise for us. It acknowledges that software is hard to write, so it’d sure as hell be hard to use and you should all be damned grateful if we allow you to use it at all.

    There won’t be expensive hands-on labs or conference talks about how to make CLI apps. Just do whatever it is you need to get the software working. We acknowledge that people are inexperienced and clueless when it comes to software, so there’s no point going out of our way to make things easier for them because it just makes it easier for them to mess it up.

    Oh, and I fixed that crack pusher bullshit that’s been going on. We’re not going to call people “users” like they’re some farm of addicts waiting for their next hit. The word “loser” doesn’t have those pejorative connotations, so in CLI that’s what we call people who interact with our software.

    I’m really excited about the CLI, and about heralding the start of the post-UX-bubble software economy. I hope you’ll all join me in making software as complicated as it deserves to be.

    Posted in software-engineering, user-error | 6 Comments

    Automate all the server Objective-C!

    I decided it was time to stop writing WebObjects/GNUstepWeb code, and write some code that would make it easier to write WO/GSW code. With that in mind I replaced my previous component generator with a more robust generator.

    I also wrote and published some git hooks for working on these projects. The pre-commit hook just runs ‘make’ and doesn’t let you commit if you can’t build: we’ll look at testing in a later post (you may not know this, but I’ve done a thing or two with Objective-C unit tests).

    The post-commit hook launches the direct connect app, so you can have a box that’s always running the latest version for testing. You’d want to do something similar, though really not the same, for a production box: as well as being sensitive to database and web server adaptor[*] configurations, you’d want to be stricter about when you restart the server, and may have some app-specific work to do like triggering cleanup code. Besides which, it makes more sense to do that in a post-update hook.

    [*] While a GSW app does include a web server, it’s common to restrict access to that server just to the internal network. Externally you have a “normal” web server like Apache or Nginx, with an adaptor that knows how to parse GSW URLs and redirect requests to the correct application.

    Posted in Uncategorized | Comments Off on Automate all the server Objective-C!

    Adding components to a GNUstep web / WebObjects app

    In WebObjects, Components take the role of a view controller in what passes for Cocoa’s version of MVC. Each is responsible for calculating the data that the view objects are bound to: you saw an example of this in the previous post. Each is also responsible for responding to user interface events—called actions—and preparing the next component where that’s required.

    Navigating between components

    Let’s add a new component to our HelloGSW test app. We’ve recorded the date that the visitor arrived at the site, we could (for sake of demonstration, not because it’s useful) find out how long it takes that visitor to get to the next page. We’ll come onto the mechanics of adding it to the project later, but for now we note that we require a way for the visitor to indicate their intention to see the next page. That means, as a simple way to do things, having a form with a submit button.

    We could write the form into the HTML, but then we’d have to know what URL the WO machinery was going to use to call our action. So we’ll use WebObjects to generate the form, using this HTML:

     <webobject name=form>
       <webobject name=submit_button><INPUT TYPE="SUBMIT"></webobject>
     </webobject>
    

    As you’ve seen, the data bindings for each webobject need to be defined in the WOD file:

    form:WOForm {}
    submit_button:WOSubmitButton {action = nextPage}
    

    As with the value binding you saw last time, we can bind the action of the submit button to a method on the component. Those of you who have used Cocoa Bindings may be surprised to find that you can do the same with NSResponder subclasses, though it’s rare to see it done with Mac apps.

    So finally, I GIVE YOU TEH CODEZ:

    - (GSWComponent *)nextPage {
      ClickDelay *nextComponent = (ClickDelay *)[self pageWithName: @"ClickDelay"];
      nextComponent.startDate = accessedAt;
      return nextComponent;
    }
    

    As with view controllers on the iPhone, you just create the new component (-pageWithName: does that, and configures its context correctly) and configure state where appropriate. Unlike with iOS view controllers, you don’t specify how they get presented because there’s only one way that will (probably) ever happen: in an HTTP response. So you can just return the next component from the method and the Right Thing™ will happen. If you return nil, the visitor will see the current component again (though with a whole server round-trip and a fresh HTML response, so it’s best to do some AJAXey thing: on which more later!).

    If you’re really interested in how the other component works, check out its source from GitHub.

    But that’s not why we’re here.

    Adding a component involves a boatload of boilerplate: five new files, and a change to the GNUmakefile. That’s one more boatload than you’d like to write every time you create a new page in your web app, yes?

    Yes. Therefore what I actually did was to write a script to do all of that boilerplate for me. It’s really basic (error checking is for security boffins. Oh, wait.) but will do the necessary dance. Just be sure not to run it twice for the same component yet…

    What I really need is a tool that’s both more robust, and that can generate the other things you need in writing a WO app. I’ll start right now, but pull requests are always welcome…

    Posted in code-level, software-engineering, tool-support, WebObjects | Comments Off on Adding components to a GNUstep web / WebObjects app

    Using Objective-C on the server

    My talk at NSConf was about cross-platform Objective-C. Those people who I talked to after the session will know that my goal is clear. There are plenty of people out there who have learned Objective-C to get onto the iOS or Mac app stores. Those people need some server-side smarts in their apps, and want to benefit from the skills they’ve already acquired. In other words: they want Objective-C on the server.

    I’m now in a position to offer that :). I took a look at the GNUstepWeb project, a reimplementation of WebObjects 4.5. It was in a fairly parlous state, and wouldn’t even build on my Mac. I’ve fixed that. It’s still a bit of a faff, but we’re in a position to start playing with server-side ObjC and see whether there’s any value in having a better product.

    Building GSW on the Mac

    GNUstep-make

    First, you need to grab GNUstep from SVN. Now you need to compile GNUstep-make, the build system. On Mac OS X you do the following:

    cd modules/core/make
    ./configure --with-library-combo=apple-apple-apple
    make
    make install

    The weird configure invocation tells GNUstep you’re going to use the Apple Objective-C runtime, and the Foundation (and AppKit) libraries instead of GNU replacements.

    GNUstep-make includes a shell script that defines the locations of various folders. You should import that into your shell environment:

    . /Library/GNUstep/Makefiles/GNUstep.sh

    Consider adding that line to your .bash_profile.

    GNUstep-base

    Then you build the GNUstep-base extensions, some additional classes and macros for working with Foundation code.

    cd modules/core/base
    ./configure
    make
    make install

    GDL2

    GDL2 is the GNUstep Database Library; an EOF-like framework for interacting with databases. If you’re going to use a DBMS like MySQL for your web apps, you should install that and its developer headers before doing:

    cd modules/dev-libs/gdl2
    ./configure --disable-gorm-palette
    make
    make install
    

    (Aside: GORM is the GNUstep version of Interface Builder. You don’t need the plugin for working with entities in GORM, and you can’t build it on Mac OS X so that’s why it’s disabled in the configure invocation.)

    GNUstepWeb

    Now here’s the good stuff. Build and install GSW. At time of writing, there’s an open bug that stops it building on Mac OS X, so you’ll need to grab the patch from this bug report. Apply that patch, then:

    cd modules/dev-libs/gsweb
    ./configure
    make
    make install

    A sample app

    You probably want to see a sample GSW app, so it’s a good job I wrote one :-). Clone the HelloGSW project on GitHub. I’ll show you how to build and run that before we get into how it works.

    Building HelloGSW

    cd HelloGSW
    make

    Running HelloGSW

    HelloGSW.gswa/Contents/MacOS/HelloGSW

    this will spit a load of output to the console, including a URL that looks like http://localhost:9001/WebObjects/HelloGSW.woa/0/. Open that URL in your browser. You should see this:

    Hello from GSW

    HelloGSW code walkthrough

    The interesting code is in the Main class, which is a subclass of GSWComponent (and conventionally the default component to show for a new visitor). Each “page” in a GSW app is a component, though of course you could arrange to return XML, JSON or any other format rather than HTML. HTML is the default and the easiest to work with, and indeed we’ll start by looking at a section of the HTML file, Main.wo/Main.html.

     <p>The time is <webobject name=now_string></webobject>.</p>

    This is clearly the paragraph that puts the date onto the screen, but you can see that there’s this weird <webobject> tag in there. That’s going to be substituted with our date object at runtime, but how? To answer this question, look at the Main.wo/Main.wod file.

    now_string:WOString {value = now}

    This file contains bindings, which if you’re familiar with Cocoa work pretty similar to Cocoa Bindings. This tells us that there’s a web object called now_string, that it’s an instance of WOString, and that its value binding is bound to something called now.

    That now binding is actually a key on the component object. We might expect to see a method called -(NSString *)now defined on Main to fill in the value of this string. Indeed, if we look at Main.m:

    - (NSString *)now {
      NSDate *theDate = [NSDate date];
      return [theDate description];
    }
    

    Where to go from here?

    The start is to build more GSW apps, and of more complexity. However there are things that need to be done along the way: all of the rest of the code and files in this project are meaningless boilerplate. This stuff needs to be hidden, automated or removed. Then we can also automate the process: compare how much of a faff setting up this app was with running a Rails app in Heroku (and I haven’t even set up an adaptor to a real web server!). It’d be really useful to simplify common tasks in modern web applications, such as exposing REST interfaces and non-HTML document formats.

    Conclusions

    Objective-C is not just a client app language. It’s got a long heritage as a server technology, but unfortunately the tools for doing that are quite out of date. They’re still useful though, so people who have come into the Objective-C fold recently can expand the use of their newly-found skills. Hopefully people will adopt—and contribute to—GNUstepWeb and help everyone to make it a useful modern server technology.

    Posted in NSConf, software-engineering, tool-support, WebObjects | 19 Comments

    More about the privacy pledge

    Plenty of you have seen—and indeed signed— the App Makers’ Privacy Pledge on GitHub. If you haven’t, but after reading it are interested, see the instructions in the project README.

    It’s great to see so many app makers taking an interest in this issue, and the main goal of the pledge is to raise awareness of app privacy concerns: awareness among developers that this is something to take seriously, and awareness among our customers that there are developers committed to respecting their identities and their data.

    But awareness is useless if not followed through, so we need to do more. We need materials that developers can refer to: the GSM Association have good guidelines on app practices. We need actionable tasks that developers can implement right away, like Matt Gemmell’s hashing guide for social apps. We need sample code and libraries that developers can rely on. We need data lawyers to explain what the current regulations are, and what’s coming down the pipe. We need to convince the industry and the governments that we can regulate our own actions. We need the ability to audit our apps and determine whether they’re privacy-preserving. We need to be able to demonstrate to customers what we’ve done, and explain why that’s a good thing. We need to earn customer trust.

    So there’s a lot to do, and the pledge is only the start. It’s off to a good start, but there’s still a long way to go.

    Posted in Business, Data Leakage, Privacy, Responsibility | Comments Off on More about the privacy pledge