Why FireMonkey is wrong, the second

I just stumbled upon a really, really great post on Steven Sinofskys Blog.

His article is about the challenges of cross-platform development in general, and he brings up some rather good points on why some approaches will eventually fail.

I’m pretty sure he doesn’t even know about FireMonkey, but this is what he has to say on cross platform libraries in general:

One of the most common approaches developers attempt (and often provided by third parties as well) is to develop or use a library that abstracts away platform differences or claims to map a unique “meta API” to multiple platforms. These cross—platform libraries are conceptually attractive but practically unworkable over time. Again, early on this can work. Over time the platform divergence is real.

And then he continues:

Worse, as an app developer you end up relying on essentially a “shadow” OS provided by a team that has a fraction of the resources for updates, tooling, documentation, ..
[…]
It is important to keep in mind that the platforms are evolving rapidly and the customer desire for well-integrated apps (not just apps that run).

The very last point is what I already stated in my own post on why FireMonkey is wrong. I didn’t even write about the even more important first ones. And this only are quotes from one paragraph where he thinks about cross-platform libraries.

I strongly suggest that you take a few minutes and read what Sinofsky wrote about cross-platform development. And then, if you currently feel that FireMonkey could be the right tool for you, try to understand his points and re-think your position on cross-platform tooling. I’m sure you will see that FireMonkey can’t be the right tool for you – or anybody.

Ask a Ninja: Where do you get your Ninja-skills from?

My second “Ask a Ninja” post is about where to get your skills from.

Well, first of all training, experimenting, using a good portion of your spare time for improving your skills. And then, of course, from others. Others that are willing to share their experience and their knowledge. Preferably in a medium that can be persisted (but also one-to-one sessions are invaluable for sharing knowledge).

Because of that I have a quite impressive library full of technical books. In the recent years I moved my library into an electronic form. I have a lot of ebooks and carry most of my library with me all the time on my Kindle. That way I can look up and re-read the important things whenever necessary. You don’t need to know everything, but you need to know where you have that information when it’s required.

So, what’s the point of this blog post you ask?

Well, I just stumbled upon an impressive library in ebook form that is available for free from Microsoft. Its a Huge collection of free Microsoft ebooks for you. They cover Sharepoint, SQL Server, Visual Studio, Web Development, Windows Store development, Azure and Windows.

So, if you want to improve your Ninja-Skills – go and grab them while their hot and start to read. And of course, spent some time to experiment with the knowledge to tighten what you just read. 😉

Ask a Ninja: Automated WordPress blog backup using Git

I thought I had posted this already, but the article list of my blog tells otherwise. Early this year I posted how I moved this blog from the old server to the current one. After that I thought I also could automate the backup this way.

So, what are the required steps?

  • Create a dump of the database.
  • Add the dump and all local modifications to the local repository.
  • Commit the changes to the local repo.
  • Push to a remote repository.

In my case I like to go sure and push to two remote repositories.

So, this is the script that will backup my blog and push it to my repos:

D:
cd D:Websdotnetninja.de
SET PATH=%PATH%;D:MariaDBbin
del backup.sql
mysqldump --skip-dump-date -u backup blog_dotnetninja.de > backup.sql
git add .
git commit -m "Automatic backup"
git push origin
git push backup master
exit

To automate the backup I just created a simple scheduled task to execute this script once a day.
Restoring the blog from the backup is as easy as described in my blog post about the move.

Ask a Ninja: Do I need Typescript?

If the .Net Ninja would have been asked this question, this would be the answer:

A few days ago Anders Hejlsberg showed a new thing currently brewing in the Microsoft labs: TypeScript.

TypeScript is:

  • JavaScript
  • + some (optional) language extensions
  • + a Compiler (more of a extractor, in fact), that removes the extensions and throws out vanilla JavaScript

The compiler itself is also written in TypeScript, so it can be compiled down to pure JavaScript and run wherever JavaScript will run too.

So, now that we know that TypeScript is a mere superset on top of normal JavaScript – what is in these additions that could be interesting?

  • Strong typing
  • Classes
  • Interfaces
  • Simple inheritance
  • Modules

Well, in fact that’s pretty much it. With some annotations in Pascal-Style (that is, colon + type identifier) you can define that a specific variable, function argument or function return value needs to be of a certain type.

var testFunc = function(arg1: string) { return "Argument was: " + arg1; };

Now the TypeScript compiler knows that only strings should be passed into the function assigned to testFunc. And it can infer from the input argument and the operation within this function, that the return value must also be a string. Now, when you try to pass i.e. a number into this function, the compiler will warn you about this, and the same goes when you want to add a number to the return value of this function.

Actually not only the compiler, but also the full IDE support in VisualStudio will highlight this as a potential problem. Also the IDE is so smart to restrict your Intellisense autocompletion to valid types only. These simple annotations are a big player in making JavaScript a bit safer when working with different types.

TypeScript also allows you, to annotate external libraries like jQuery, Prototype, Qooxdoo etc., and it comes with some of them already pre-annotated to give you a head-start.

The other interesting thing is that the way of modularizing the scripts sticks strongly to what is currently proposed to become the next EcmaScript 6 standard. Of course this is only a specification draft by now, and will take some time to be finalized, and it is not sure if the specs will stay this way forever, but this way it is very likely that what you learn with TypeScript can be used in the future for vanilla JavaScript too.

Ask the Ninja: “So, do I *need* TypeScript?
Ninja says:
Need as in totally and absolutely required? Of course no.

TypeScript is an addition to JavaScript that, if used correctly, can help you avoid some nasty bugs. And only, if you are a fan of strong typing and come to JavaScript from other strong typed languages on the .NET or Java Platform or even from Delphi. Then TypeScript is targeted for you!

When you already are a happy JavaScript developer and make use of the dynamic typing features of the language, switch prototype chains on your objects as required and love applying and removing things at run-time, then there is nothing in TypeScript for you.