Of course the question is, which Apple certifications are the best? Well that depends on what you’re going for. If you work for a company that is considering transitioning to a Mac based workforce, then get the Mac Integration Basics Certification. This certification specializes in integrating a Mac machine into a Windows based network and confronting the issues that may present themselves during the process. Or maybe you’re wanting to change jobs and you’re looking to be valuable to a company that has already made the shift. Then go for the Apple Certified Macintosh Technician (ACMT) Certification. A ACMT certification shows prospective employers that you’re not going to get hired and start complaining about how compact and “busy” the inside of a Mac is. You’ve seen it all before!. You could also go with one of the three OS X Lion Certifications offered.

Of course I’m not saying that the you should get an apple tattoo, build a shrine to Steve Jobs and start going to Starbucks. As Ryan Faas points out in his article the Apple certifications are best as only part of your certification collection.

To hunt down the bug, I used the excellent JProfiler to see if it would give me a clue as to what was going on. Here is a screenshot.

It turned out that the leak was actually in one of Sun’s own JAI classes, which have not seen much development in recent years. The jpeg2000 image reader seemed to be holding on to some resources even when the reference to the J2KImageReader instance had been released in our code.  In the screenshot you might be able to see there is 670 odd kilobytes and just over 15 thousand instances still referenced.  I looked at the reference graph in JProfilier for some of the instances and ended going round in circles!

I decided that I would have to look at the jai-imageio code to see if there was something to be done.  At this point I also realised that some of our JAI links where broken and that JAI seems to be pretty much forgotten about.

After having a look at the JAI image-io code I decided to use a pretty straight forward strategy to release the memory: set some object references to null somewhere along the line!  The J2KImageReader class seemed to be the place to start.  While having a look I realised that the J2KImageReader class did not implement a required dispose method.  When we called dispose it was just calling the super implementation of dispose in the ImageReader class.  This is an empty method with a comment saying that subclasses must implement their own dispose method.  I created a dispose method, nulled out J2KImageReaders private object members, rebuilt the image-io jar and ta-da!

No more memory leak!  Which was pretty cool.  The next part was a bit more difficult: commiting my change back to the jai-image-io repository, I faffed around for too long trying to see if this is still possible.  In the end I gave up!  I heard a rumour that the guy administrating the code does not work for Sun/Oracle any more, but if you have had any success comitting your changes to some of the old projects hosted on java-net then please drop me a line.

Anyway, if you are having the same problems with JAI, memory leaks and jpeg2000 I have added the image io jar rebuilt with my change to our website so you can download the jai image io jar if required.

And if you work for Oracle, can you tell me where to send the patch?

Comments

Programmers, you should check this out. Cloud9 IDE has the biggest innovation in IDEs since Microsoft brought us Visual Basic: everything runs on the cloud.

It’s “development as a service.”

What does that mean? Well, instead of coding in text files sitting on your computer, you code directly in the browser window. Here Rik Arends, CTO, and Ruben Daniëls, CEO, show me how it works and explains what it’s good for.

“It’s aimed at developers who want to use the new stuff,” they say.

What do you think? Will you build with it?

Comments

Like most of the C++ programmers I know or have met, most of us have been taught that C++ is an Object Oriented Programming Language. I’d like to put an end to that now, and say that C++ supports the Object Oriented Programming Paradigm. Let me try and separate the paradigm from the programming language first.

Paradigms

A Paradigm is:

From the 1960s onward, the word has referred to thought pattern in any scientific discipline or other epistemological context. The Merriam-Webster Online dictionary defines this usage as “a philosophical and theoretical framework of a scientific school or discipline within which theories, laws, and generalizations and the experiments performed in support of them are formulated; broadly : a philosophical or theoretical framework of any kind.”

– Wikipedia Entry on Paradigm.

The Wikipedia article on the matter describes it in a way that suggests that it is a way of thinking, of reasoning, and of formulating intellectual constructs. Therefore I submit, that the Object Oriented Programming Paradigm is merely one way of modeling solutions in terms of objects. Why is the distinction between the paradigm and the programming language required?

It’s funny us humans have a way of associating words with concepts. If you say something is an Object Oriented Programming Language, then it can’t be anything else right? But C++ is not that at all. C++ supports the same programming paradigm that C supports — which is the Imperative Paradigm — and the Object Oriented Paradigm as well as some concepts in the Functional Programming Paradigm. C++ has one powerful programming paradigm that it supports which not a lot of other programming languages support: the Generic Programming Paradigm.

So let’s start out first by showing that C++ is not just an object-oriented programming language. Let’s take one tenet of OOP and let’s implement the same using GP. Let’s try Inheritance first.

Bucking Inheritance

In C++, you can define a class which inherits from another class using four different types of inheritance (public, private, virtual, and protected). If you need to see how that’s done in C++, look here. This is one of the three basic tenets of OOP, so how do you do it with GP? The answer may be surprising: you don’t.

In Generic Programming, inheritance is just an implementation detail of a type. What’s important in Generic Programming is not the type, but the characteristics or the requirements on the type. If you’re familiar with Python and Duck Typing, then you’ll understand how in GP you pretty much rely on the same thing:

template <class Duck>
void foo(Duck & duck) {
  // do something with duck here
  quack(duck);
  quack(duck);
  kill(duck);
  cook(duck);
  eat(duck);
}

The way I put it up there, it really doesn’t matter what the type of `duck` is: what matters is that, for the function `foo` to compile, then there should be functions `quack`, `kill`, `cook`, and `eat` that take in a parameter of type `Duck`. What `foo` is doing is imposing requirements on the type `Duck`. We can then reason about the requirements on the types, rather than the ancestry of the type. This is what Concepts are. More specifically:

A concept is a set of requirements (valid expressions, associated types, semantic invariants, complexity guarantees, etc.) that a type must fulfill to be correctly used as arguments in a call to a generic algorithm. In C++, concepts are represented by formal template parameters to function templates (generic algorithms). However, C++ has no explicit mechanism for representing concepts—template parameters are merely placeholders. By convention, these parameters are given names corresponding to the concept that is required, but a C++ compiler does not enforce compliance to the concept when the template parameter is bound to an actual type.

– Boost.Concept_check

So let me say that again, you can forget about using Inheritance in your C++ programs to model requirements on parameters to algorithms and use Generic Programming instead. This means you use Inheritance for other more useful means (that does include limited forms of re-use) than modeling an “is-a” relationship.

Paralyzing Polymorphism

Next up in my OOP hit list, I’ll take on polymorphism. Inheritance is not so interesting if all you’re doing is taking on the properties of the parent type (in C++’s case, you can multiple parents — and believe me, that’s a good thing, but that’s for another time). If you’re using Java you have at your disposal a very nice concept of the `interface`. This concept is very important, but at the same time very rigid in the light of OOP.

In C++ you have the “virtual” keyword where you describe a class’s member function to be a virtual function, so descendants of that type can override the functionality of the function and the proper dispatch can happen at runtime. This is a very powerful concept that a lot of software is already built upon. My point is that it’s not all the while pointless, it is perfect for situations where you need the kind of dispatch necessary. However, there is a different way of doing it at runtime.

Like the earlier point I was trying to make about Inheritance, GP doesn’t rely on structure or hierarchy of types to implement algorithms. The sad part about runtime polymorphism as implemented by the C++ virtual keyword is that it still relies on inheritance for the override to happen. Luckily, there’s a good alternate to this method that works just as well.

The problem the virtual keyword is trying to solve is that of runtime dispatch. If you think about it a little, all that is really necessary is to call the correct function based on the type of the parameter — or the type of the object for that matter. There are two ways of achieving this with GP:

1. Tag Dispatch. The common pattern for Tag Dispatch relies on performing static or compile-time checks for the type of the parameter, and calling the appropriate overload implementation for the actual function.
2. Function Wrappers. The idea is you should be able to perform runtime dispatch based on criteria other than just the type of the object that hosts the virtual member.

With Tag Dispatch, you can perform the wiring at compile-time reducing the need for runtime dispatch. If for example you already followed the advice of bucking inheritance for function parameters, you can then think about doing the dispatch based on the type of the parameter too:

template <class Duck>
void foo_impl(Duck & duck, already_dead) {
  // no need to check if duck is alive nor kill it
  cook(duck);
  eat(duck);
}

template <class Duck>

void foo_impl(Duck & duck, wild_and_dirty) {
  quack(duck); quack(duck);
  kill(duck);
  foo_impl(duck, already_dead());
}
template <class Duck>
void foo(Duck & duck) {
  foo_impl(duck, typename Duck::tag());
}

This static dispatch is useful if you just had a lot of different duck types, and just place a nested type `tag` on each type that was either `already_dead` or `wild_and_dirty`. This saves you a virtual function call, or an if statement to check whether the type of the duck is a live one or a dead one. You can then see how building algorithms in this sense makes your functions more generic and more extensible — if you have a different specification based on a new tag, you just add that tag dispatch overload and you’re done with it.

With Function Wrappers, I’d point you to Boost.Function and Boost.Bind — I’ll leave you to imagine a simple aggregate type that you can easily initialize with the correct function wrappers to specific implementations, which you then deal with in your algorithms.

Edifying Encapsulation

There’s nothing really bad with the concept of encapsulation, except that this usually means it’s time for the tightly coupled game. What I mean by this is you then have types that know about other types in a manner that usually it wasn’t intended to know. Think about it this way: Java used to have collections that only dealt with Object references — you had to cast them Object references into specific class references on your own. This is just bad design — think about the last time you had to write a container type that wasn’t really re-usable in a different context other than your application, and you’ll see why that feels wrong. Think about the way Python or Ruby deals with lists and you don’t know what the elements of the list are — and it’s too late to find a bug when you accidentally append a string to a list that was only meant to contain integers — and then you’d wonder why these are “modern” programming languages.

Contrast that to the way the STL containers work: containers have one implementation (well, except for the ugliness that is std::vector<bool>) and you supplied it with the type of the things it contains. That is a good way to think about encapsulation in GP. The point of encapsulation is that the algorithms that deals with a data type’s internal state is encapsulated in the implementation. Notice I didn’t say ‘type’ or ‘class’ and instead meant ‘implementation’ because if you look at the tag dispatch example above, you can totally implement an algorithm external to a class and still treat is as part of the implementation of a container.

What’s also good about the STL container implementations is that they define the concepts that each container models. This means anybody can then implement their own abstract data type and model the Associative Container concept that the STL provides, and then have their implementation suddenly usable where algorithms rely on an Associative Container. Notice that doesn’t mean anybody needs to derive from the same base — which removes all notions of coupling all together. In GP, even the weakest of coupling is too strong, and isolating the components and algorithms from the details of types is the whole idea.

Outro

This is the second day I’ve written something longer than a thousand words on the blog, and here I’m attacking one of the fundamental things that makes C++ totally misunderstood which is the assertion that C++ is an Object Oriented Programming Language. Others before me — and far more experienced than I am when it comes to developing things in C++ — have already read countless number of articles and books about the subject. The one that prodded me most and got me into more into the modern way of doing C++ is the one by Andrei Alexandrescu about (well, what else) Modern C++: Generic Programming and Design Patterns Applied.

The next time you’re designing another C++ application or thinking of improving the extensibility and re-usability of your code, think about doing it in the modern C++ way and use Generic Programming instead of just boring all rigid Object Oriented Programming. I guarantee it will change the way you do C++ programming and how much cooler C++ programming can be.

Comments

Before I dive into the points, let me just give a quick backgrounder on what Agile Software Development is. Notice I didn’t mention any specific methodology, and this is because being Agile is more a state of mind than a rigid set of practices — if anybody tells you otherwise, they might be misunderstanding the Agile Manifesto.

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.

– Agile Manifesto

So what are the hallmarks of Agile Software Development? For one thing, the premium on:

• Iterative Development — building software in a way that allows for quickly changing implementations over a period of time, and making sure that something gets delivered and iterated on.
• Testing — having tests to ensure that components of the system (and the system as a whole) works as specified.
• Welcoming Changes — instead of having lengthy planning, the solution is built to assume that anything at any given point later on can (and probably will) change.

In the world of dynamic languages and object-oriented systems, is there a place for Agile development with C++? Well, of course the answer is yes!

Because Agile Software Development is a process or a “way of building software”, the tools you use aren’t largely affected — but the practices you follow might be affected. For example, instead of writing lengthy design documents, you’d rather write code and generate the design document out of the code; instead of writing specification documents, you actually write unit/integration/system-level/acceptance tests; instead of having planning sessions you have quick 5-minute meetings and more collaborative modes of development (pair-programming, for example). Now other languages have tons of tools that help with making these practices more in-grained in the development process — things like one-click unit-test runners and continuous testing environments (that build and run the tests as soon as changes are being made to the code for immediate feedback).

I for one have been following different practices in the various Agile C++ projects I’ve been involved in.

• Test Driven Development — In any software I write now, I feel like fish out of water if I don’t write the tests first to define what I require from the component I’m writing. Having tests to verify both your specifications and implementation are actually sufficient saves you from the guesswork you otherwise have to go through when developing software. Having a deterministic and honest — even automated — way of making sure you’re understanding the specifications and implementing something acceptable is definitely the way to go in case you intend to make changes along the way.
• Active Code Review — In all the previous software projects I’ve been involved in, there is no sacred code and everything is subject to review (and improvement). This makes people care about the code they write and the design decisions they’re making. It also ensures that everybody is made involved in the process of developing and learning from the code that’s being developed.
• Pair Programming — I swear by the productivity improvement of pairing developers up to work on the same part of the system. The additional support and guidance you get from an additional set of eyes really affects the way I write code and the way I approach problems. The best part about pair programming is not the part where you’re writing code, but the part when you’re talking out the approach and the design decisions before writing — or while writing — any code.
• Brutal Retrospective — It’s important to stay honest when coding to see where the faults and issues are and be able to say what these are and how they should be addressed. There’s no point in sugar-coating the state of affairs especially when the success of a project is at stake. In other words, call it as you see it, and learn from the experience by making changes along the way.
• Measure Progress and Productivity — It’s great to be able to measure the actual productivity of a team and be able to adjust as you go along in the project. There are a lot of ways in which progress and productivity are measured, but the details don’t matter as much as the fact that measuring it matters. Do it however you like, but just make sure you’re measuring progress and productivity.

Overall I’ve been in various roles in the Agile projects I’ve worked with in the past. Having a clear understanding of what your software needs to do and what the customer wants is key to the Agile process. The clarity yields happier customers and better software in the long run, and even improves developer productivity by being able to focus and iterate on the solution rather than trying to design it right at the start.

So have you been part of an Agile Software Development project lately with C++? How did you find it? Did I miss anything obvious above?

Comments

The six developer guides may not appeal to non-coders, but for those hard-core, full blown coders, choose between titles like iOS Human Interface Guidelines, Object Oriented Programming With Objective-C, or Cocoa Fundamentals Guide. Wait a minute, you don’t have to choose, they are all gratis. The other three titles are The Objective-C Programming Language, iOS Technology Overview, and its thrilling sequel iOS Application Programming Guide.

You’ll need to fire up iBooks on your iPad or iPhone to get these books since Santa only climbs down these chimneys to drop off your presents. Apple says that these free books work best with the recently-released iBooks 1.2.

Comments

For those currently seeking the CCSP security certification through Cisco or for those that will need to re-certify in the future and need to know how they fit in the new security certification structure, Cisco has detailed the necessary migration path. They even provide a handy “CCSP Certification Tool” that helps ensure that your investment in your certification is not wasted.

In its outlook for 2010, CertMag quoted Fred Weiller of Learning@Cisco as saying, it “…matters how quickly you can react to different situations. Fewer people with broader knowledge can act faster.” Choosing a vendor-neutral certification means that you have more reusable knowledge that is not relegated to a specific company’s product. Vendor-neutral certifications are based on industry and international standards that not only means that the knowledge can be leveraged in more scenarios, but also that the acquired knowledge does not age into obsolescence as quickly as a vendor-specific certification. Vendor-provided certifications have also been known to evangelize their technology to the point of bias. Vendor-neutrality disabuses the certification process from certain marketing encroachments. You can search on GoCertify for vendor-neutral certifications. Consider the various certifications from CompTIA, Brainbench, or Certification Partners.

An information technology professional should never merely constrain his or her certifications to main technology vendor that their employer or industry uses, but should complement vendor-specific certifications with ones that are vendor-neutral. Having both makes you a more flexible IT professional who is able to adapt to the changing market-place. With the recent and predicted growth of IT in many diverse industries, being more well-rounded is invaluable.