On Australian housing affordability

Read Later

From ABC PM's Friday bulletin:

MICHAEL JANDA: But the founder of Meriton, one of Australia's biggest apartment developers, dismisses the concerns about affordability.

HARRY TRIGUBOFF: The people are the young ones that can't buy in the area they want, there's not many people by the way, they talk a lot. Why they talk a lot because they would like to buy cheap and sell dear but they haven't got the guts and haven't got the money.

Class.


Rubénerd for the next ten years

Read Later

A few of you have noticed some c-c-changes around here. As a blog reader myself, I know there's nothing better than meta blogging, so here we we go.

First, I've all but revered back to my 2011 theme. Save for my 2004 rainbow tabs, this is one of the few themes I'm almost proud of. It's simple, but somewhat more interesting than the generic one column stuff being peddled thesedays. It also matches my business card site, sort of.

Second, I moved cloud providers. Clara's and my tiny instance is now running on a Debian nginx stack in an Equinix data centre in Sydney, Australia. The difference in performance and reliability is pretty eye popping, which I otherwise wouldn't recommend doing. The company also has excellent, handsome support.

Which gets us to the final, and arguably most important point. Which means it should probably have come first. Darn.

As you've all probably noticed, I've barely been blogging lately. When I started this site almost ten years ago, I had all the time in the world to blog and podcast. Today, many other commitments have evaporated all but a precious amount of introvert-sustaining personal downtime. I still love writing and sharing ideas though, so what to do?

Adapt!

To do so, I'll be thinking about ways to make the site simpler to maintain and write for. No more mandatory post images? Textile or Markdown instead of HTML? Become one of the cool kids and linkblog? Ditch social networks that take ownership of our content, and focus that energy here? Who knows.

One thing is certain, no matter what form it takes, I'm determined to take Rubénerd into another ten years. What can I say, you've been a gracious audience :).


Happy birthday @hanezawakirika!

Read Later

The Kiri with her Nemuneko!

It wouldn't have been hard to top Clara's birthday last year. I'd broke my ankle a few days prior. Infinitely worse however, she had an exam on the exact day. I mean really, how positively evil is that?

Suffice to say, this weekend was far nicer. We had Taiwanese tea and food with friends, caught an exhibition at the PowerHouse Museum, goofed around at home and exchanged more Nemuneko than perhaps one should!

I'm back at my VMs this evening, but just wanted to send one final warm Happy Birthday to Clara. The competition is less than steep once more, but you would look infinitely nicer in a tutu than me. ♡


Thinking of @CaseyLiss when learning C#

Read Later

With potentially my last C# project at university wrapping up, I thought I'd share some "outsider" experiences with the language before bidding it farewell.

Skip this nostalgia crap

My first experience with C# was in high school. At my weird Australian International School in Singapore, a bunch of us did accelerated Software Design and Development. Unfortunately, the course should have been called Software Algorithms, as there was no officially mandated development in the silly-bus. VB had been used to demo ideas, which I translated to VB.NET at home, then made the leap to C#. It seemed oddly familiar, almost like VB.NET expressed with C syntax. I was about to learn there was far more to it!

My dad bought me The Petzoid Book at the time. I've since learned it's the Perl Camel or Ruby Pickaxe of the C# world. Even as a Mac and *nix guy now, I do like how the book flows, and many pages have been folded and spilled with coffee. Good times.

But I digress. Sitting at UTS this year, I couldn't help but smile as all this nostalgia washed over me. In some ways C# has changed markedly since I moved off Windows in the 2000s, but in other ways it was its old familiar self. In fact, it was almost... too familiar; doing Java and C# in the same semester was a recipe for confusion and misplaced syntax.

Data types

In Java and C#, Strings are reference data types. In C#, lowercase "string" is a keyword alias, so we can use both interchangeably.

string Greeting = "Nyanpasu~";
String strcopy = "Look ma, no pointers!";

Simpler data types such as int are actually structs. Remember those from C? More on those shortly.

Auto-implemented properties

An interesting, almost Ruby-esque feature is auto-implemented properties. There's insufficient for complex classes, but if you're mostly encapsulating simple properties, you can avoid all that nasty Java getter/setter boilerplate. For example:

class Character {
    private string name;

    public string Name {
       get { return name; }
       set { name = value; }
    }
}

That I had seen. Since I was gone, C# further simplified it:

class Character {
    private string name { get; set; }

    public Character(string name) {
        this.name = name;
    }

    static void main(string[] args) {
        Character ryuuji = new Character("Ryuuji");
        Console.WriteLine("Hello, {0}!", ryuuji.name);
    }
}

Brackets and evil

I like K+R C brackets, but Visual Studio defaults to newlines, and most documentation uses them. To each their own, but I feel they just add tedious scrolling. Though we can all agree they're far nicer than the hideous GNU recommendations.

C# also allows eschewing (gesundheit) brackets for single line conditional statements and loops. If you think that's bad enough, they also allow GOTO lines.

if (true)
    goto hammerspace;

Die twice, already!

enums

Compared to Java 5+, enums in C# are limited to just representing named constants. This reduces overhead, but you'll need to break out a new class for anything more.

private enum Scale {
    Tsundere,
    Yandere,
    Kuudere
};

static void main(string[] args) {
    Scale tiger = Scale.Tsundere;
    if (tiger == Scale.Tsundere) {
        Console.WriteLine("It's not like I wanted to be an example...");
    }
}

structs

One of the first questions I had when learning Java regarded all the syntax errors my structs were generating. In C#, they're still a part of the language, and are encouraged over fully blown classes for simple data structures due to their lower overhead. The primary practical difference (I can see) is they don't support inheritance.

const and readonly

By now I was starting to realise C# was a little more like C than Java, at least in some ways. My const-antly appearing friend is here, and she brought an initialise-at-runtime companion in the form of readonly:

public const OVER = 9000;
private readonly bool nice;

public Character(bool isNice) {
    nice = isNice; // daijoubu~
    OVER = 2000;   // oh no, you didn't
}

out and ref

I have mixed feelings about these. Broadly speaking, they allow you to pass value types by reference. With out, you must pass it an uninitialized variable, which must then be given a value within the function.

void Process(ref int x, out int y) {
    x = 10;
    y = 20;
}

static void main(string[] args) {
    int x = 1;
    int y;
    Characters.Process(ref x, out y)
    Console.WriteLine("x is {0}, y is {1}", x, y);
}

==> x is 10, y is 20

Namespaces

In most languages I've encountered, we declare the namespace for a class in the source head. In C#, namespaces contain the class within brackets. I can see the pros and cons for both approaches.

namespace Animu {
    class Characters {
        // put methods and attributes here, desu
    }
}

Conclusions

So, that's the end of part one. I have another post queued up with a comparison of Java and C# generics, anonymous and delegate functions, some other random pieces like coalesced nulls, sealed classes, and a brief look at reflections and Linc. No wait, Linq. Clearly I need to select my words more carefully. GET IT!?!? AAAAA... nevermind.

I don't see myself ever writing C# professionally, though I've found the trip fascinating and can see why the Casey Lisses (Casey Lissii?) of the world like the language. At the risk of alienating some of my readers here, I would prefer it to Java. Should I be cowering in a bunker somewhere now?

That said, I aspire to have more Swift and Ruby in my immediate future. And $perl, because it was my first love. Shaddup.


Remember SOAP?

Read Later

Official soap provider for the RMS Titanic, no less!

It's been a long road. Several aborted starts, extenuating family circumstances, international moves, degree changes and restarts. Still, I'm less than a week away from finishing my last full time semester at uni, and I'm royally excited.

Which gets us to the issue at hand. One of the topics we have to study for tomorrow's exam is SOAP, or the misleadingly titled Simple Object Access Protocol. It's been around so long, I won't bore you with lame puns about overscrubbing you've probably all read a million times by now.

I hadn't done too much with the technology before, and certainly never attempted to implement it. My memories harken back to the mid 2000s, ironically at my first university in Adelaide, and a small web server we had to communicate with over... get this... SMTP. Turns out, SOAP is utterly application layer agnostic, so you don't even need to use HTTP.

Hey look, Wikipedia even uses SOAP over SMTP as an example. Go figure, we're not allowed to use it as a reference, but our lecturers can.

(Not that I'm suggesting anything there, of course. Other than the fact I've caught lecturers at UniSA and UTS using Wikipedia material in their slides. That Creative Commons licence does require attribution, guys).

But I digress, what makes SOAP?

In a fatty acid nutshell, SOAP is an XML based messaging protocol for "calling procedures on other machines". Information is transmitted in SOAP envelopes with the following components:

  • A header, which outlines the features of the SOAP message
  • A body, with the primary information for the message recipient
  • An optional fault section to describe encountered processing errors

Of course, how do we know what services are available and the type of data we can expect to receive? For that, we turn to more XML in the form of the Web Services Description Language. These documents define:

  • Services, expressed as ports/endpoints and bindings
  • Ports/Endpoints, the connection point to a web service
  • Bindings, which map operations to protocols, such as HTTP
  • PortType/Interfaces, which defines performable operations
  • Operations, or abstract descriptions of supported SOAP actions
  • Messages, which define sets of parameters
  • Types, which define data types used

(I'm sitting in a coffee shop while I write this, and the Hornsby Shire Council just started playing My heart will go on. I'm picturing all these people RESTing in lifeboats while this bar of SOAP slowly sinks beneath the waves under its own weight, with suds and bubbles still gurgling from its tallowy funnels).

But I digress, can we look back in time with this?

SOAP is a fascinating time capsule into how developers and designers thought web services would shake out in the late 1990s and early 2000s. Along with WSDL, the designers had bold plans for registries where web services could publish their capabilities. These were defined in yet another XML format, called the Universal Description Discovery and Integration protocol.

While the web has moved on, and UDDI has become the stuff of history, SOAP is still used in more places than I appreciated. According to Alex Williams:

I asked Michael Cote of RedMonk for his opinion on about why SOAP is still used in the enterprise. "Existing applications that use it and Enterprise Architects who still want to enforce a top-down, well, architecture with it."

So that's why universities still teach it.