Wednesday, October 31, 2012

Code and Blogger

Earlier this week, I took a personal decision to invest more time blogging.
As the majority of my posts will be, most probably, technical - I guess that embedding code snippets into my blog, will become a common scenario.

It's quite strange for me that blogger doesn't have built-in mechanism for beautifying code snippets; after all it's Google, isn't it?

In order to move on, I'm looking for a a strategy to embed code snippets right here.

This is not the first, nor the last discussion on the topic, but I found this stackoverflow thread very informative.

My love-at-first-sight was gist.
Gist is a simple way to share snippets and pastes with others. All gists are git repositories, so they are automatically versioned, forkable and usable as a git repository
  1. It's easy
  2. I trust github to host my code, so naturally I do for my snippets
  3. Code formatting and syntax-highlighting is beautiful
On the down side:
  1. Editing an old post require editing of both the blog source here at blogger, as well as the gist at github
  2. Page load will have to wait for the gist script parsing
  3. I can't see the code when I'm typing in the blogger editor. (gist is being embedded only at runtime)

Embedded gist will look like this:




Second option is to add to my blogger's template client implementation of code formatting and syntax highlighting.
Syntaxhighlighter is here to help a developer/coder to post code snippets online with ease and have it look pretty. It's 100% Java Script based and it doesn't care what you have on your server.
This will give a whole new meaning to the <pre> tag wrapping your code.
Taken from the demo site:

// SyntaxHighlighter makes your code snippets beautiful
var setArray = function(elems) {
    this.length = 0;
    push.apply(this, elems);
    return this;
}

This will allow me to see the snippet while editing the blog, and the result is satisfying.
But again, it's a runtime technique that require adding additional scripts and styles on top of the blogger template. The implication is more time to wait before you can actually start reading this. Performance is too important.

Last but not least is the <pre> tag which is according to the spec:

The <pre> tag defines preformatted text.
Text in a <pre> element is displayed in a fixed-width font (usually Courier), and it preserves both spaces and line breaks.

It is embedded and dependent only on the browser, it is supported on all browsers and even on almost browsers ;) and it's integral part of the post source.
True. It doesn't get the wow effect that real syntax parser can make, but I like the result; I even think it looks classic.

A Javascript snippet wrapped in an <pre> tag will look like that:


   var Person = Ember.Object.extend(Ember.Evented, {

        /**
         * @property name {String}
         * @public
         */
        name: null,

        /**
         * Called when the name property has changed.
         * @event nameDidChanged
         * @param newName
         */

        /**
         * @method
         *
         * raise an {@link Person#nameDidChanged} if value of {@link Person#name} has been changed
         *
         * @private
         */
        _applyName: function _applyName () {

            this.trigger('nameDidChanged', this.get('name'));

        }.observes('name')

    });


I do think that I will go for the pre tag for now.

KISS,
Eran

SAP NetWeaver Cloud Portal

Hi there,

I wanted to share with you the beautiful NetWeaver Cloud Portal.
In addition to having my first boy, this is the greatest achievement I was involved in the last year.

You can check out the consumption experience here, or read my blog about UI technologies we used in this project.

Enjoy,
Eran

Thursday, December 22, 2011

The mobile development debate



It's clear now. You're doing mobile, everybody doing mobile.


Whether it's an apple device, an android powered smart-phone, or someone else (is there anybody out there?), we're all moved to the new jargon. Click's and dblClick's are dead. Our new friends are the entire Tap family, along with swipe and pinch.
This rapidly-growing trend, must change somehow the way we think. In many aspects, we're yet to realize what is the full meaning of mobile development to us.
In the following read, I would like to try sharing some of my thoughts regarding the million smart-phones question:


Will it be native frameworks? Mobile-Web (or hybrid)?


For those who are not familiar with the subject, I will try to sum it up shortly:


  1. We have a small number of very big fish who are doing mobile OS's: Apple (iOS), Google (Android), RIM (Blackberry OS), Microsoft (the almighty  Windows Phone), Symbian and WebOS from HP.
  2. Each of them provides some SDK that allow you to write apps. These App will fit just fine on a device that runs this big-fish's code, but it will not work on some-other-big-fish's device
  3. These apps are being called Native apps (make sense; isn't it?)
  4. The native App can speak with almost any other neighbour-component on the underlaying device (phone, Camera, location services, contacts)
  5. The mobile-machines also run one special app that called browser, this browser can always understand HTML, JavaScript, and CSS
  6. HTML5 is big. Very big. Is it the next big thing? No it isn't next. It's already here.
  7. Now, the 1+1 here is that the same html code can run inside any device, with a little help from a browser, which is already there.

Native Frameworks


The native frameworks introduce top notch technology. 
In the Apple Campus as well as in Googleplex a huge effort is being consistently put into iOS and Android, respectively. The best engineering teams in the world are working only to make it easier for the rest of us. The formula is simple: the easier it will be for developers to develop Apps with your framework, the more Apps you'll have in your App store/market/whatever.
Check out the Apple iOS dev-center, 99 bucks, and you're in developer's heaven. If we speak about revenue model, Apple will eat 3 pieces of your cake, you will get 7. If you sell enough, that's enough to make you happy.
Other than that, Native Apps are born to be quick. A web-app is running inside a browser that is running inside an OS. An App is running inside an OS. Generally speaking, the second approach will be faster.
As a Native App, as I already mentioned above, you'll enjoy natural API's for other components. If you'd like to add some photography functionality to your app, for example, you'll just need to copy n' paste some snippets.



Mobile Web


"The Mobile Web refers to the use of Internet-connected applications, or browser-based access to the Internet from a mobile device." (wiki).
I prefer the second definition. I find it useless to mention not-connected applications, there is not much we're doing offline today. So, we are actually debating here about client technology.
So why go HTML'ish?
I can count many reasons:

  • JavaScript is usually one of the 5 most popular languages. A tremendous number of developers out there already feel at home with JavaScript, HTML and CSS.
  • You only need to write your App once. (a web expert might argue saying that different browsers have also compatibility issues; He'll be right. But hey: it will still cost less then writing it all over again)
  • No revenue model splits. You can eat the whole cake.
  • HTML5 introduces some very nice features that will make you feel almost native (Geo-location and location services, Web-sockets, offline modes etc.)
  • You can update/ fix you're code without popping-up and asking the user to update.
  • You have excellent frameworks to support you. I love Sencha Touch so much, so I don't want to mention no one else here.


My two cents


We're definitely going more and more web. 
On the other hand - If it's looks like a browser, it's probably a browser. On our civilization browsers have security restriction, and always will have. No one will ever want to give a web site the potential capability of reading his contact list, or start reading data from his file system.


So it'll probably be both:
Web sites, that are pure HTML, CSS and JS, running inside a web container which is wrapped-up and deployed as a native app.
Take a look at PhoneGap for example. They're already doing it today.
We'll probably have to wait and see.


If you don't think about the future, you cannot have one. (John Galsworthy)







Monday, March 14, 2011

This is my first blog

So...
This is my first blog ever, preety exciting.
Here is a sneak peak of what I've started to do just two days ago:
https://wsod-demo.sap.com/session/new