CD Ray - Designer and Developer

Android Tutorial

2012-03-22T20:24:00.000+05:30

Android , an open source operating system for mobiles devices (smartphone and tablet), led by Google. The Android SDK provides a set of tools and APIs to develop Android application, using Java. So, if you know Java, Android programming is easy .

In this series of tutorials, we show you the list of basic tutorials to get you start program Android easily.
Note
All Android tutorials are developed in Eclipse 3.7, and tested with Android 2.3.3.

P.S This is just the initial version of Android tutorials, will keep publish more in future.

1. Quick Start

Get you start in Android programming.
Android hello world example
Tools and SDK to develop Android application.

2. Fundamentals

Some Android basic stuffs.
Android activity example
Understand Android’s activity, a simple example to navigate from one screen (activity) to another screen (activity).
Android wrap_content and fill_parent example
The different between wrap_content and fill_parent to control the component’s width and height.
Attach Android source code to Eclipse IDE
Android source code is important to understand how Android works, a guide to attach Android’s source code to Eclipse IDE.

3. User Interface Controls

Play with Android UI controls.
Android button example
Use “Button” to display a simple button.
Android textbox example
Use “EditText” to render an editable textbox component.
Android password example
Use “EditText” + inputType=”textPassword” to render a password component.
Android checkbox example
Use “CheckBox” to render checkbox component.
Android radio buttons example
Use “RadioButton” and “RadioGroup” to render radio buttons component in group.
Android toggle button example
Use “ToggleButton” to render a button which has only two states (On and Off).
Android rating bar example
Use “RatingBar” to render a rating bar in stars icon.
Android spinner (drop down list) example
Use “Spinner” to render a drop down box for selecting items.
Android date picker example
Use “DatePicker” and “DatePickerDialog” to render a date picker component.
Android time picker example
Use “TimePicker” and “TimePickerDialog” to render a time picker component.
Android analogclock and digitalclock example
Use “AnalogClock” and “DigitalClock” to render a clock like component, which supports hours, minutes and seconds.
Android progress bar example
Use “ProgressDialog” to display a progress bar in dialog to tell use that your task is takes time to finish.
Android alert dialog example
How to display a alert box.
Android prompt dialog example
Custom AlertDialog example.
Android custom dialog example
Custom Dialog example.
Android Toast example
Custom Toast view example.
Android ImageView example
Use “ImageView” to display an image file.
Android ImageButton example
Use “ImageButton” to display a button with a customized background image.
Android ImageButton selector example
Use “Button” and “selector” tag to display button’s images depend on the button states.

4. Layouts

Play with Android layout controls.
Android LinearLayout example
Most common layout, arranges components in horizontal or vertical order.
Android RelativeLayout example
Most flexible layout, arranges components base on the “relative” or sibling component.
Android TableLayout example
Most flexible layout, arranges components in row and column format, just like HTML table , <tr> and <td>.
Android ListView example
Display components in a vertical scrollable list.
Android GridView example
Display componenets in a two-dimensional scrolling grid.
Android WebView example
Allow you to open an own windows for viewing URL or custom html markup page.

5. FAQs

Some common asked questions in Android.

References , You might also like this tutorials :

Android Developer
Android Fundamental
Android in Wikipedia

People Around The World

2012-03-01T00:15:00.000+05:30

Another one in the ‘series’ of fun and happiness… Some real nice shoots in this video. From the fastest climb on Mt. Eiger (BTW, the Eiger (3970 m (13025 ft)) is a mountain in Switzerland.) to some amazing base jumping. Not to forget some days in the snow that only the true lucky ones are getting the chance to experience.

Web Development – Some ‘Good To Great’ Tools

2012-02-20T23:57:00.002+05:30

If you got some other good sources please let me know… Here is the list:

Browser capability

Before you start your project you need to check what is the set of features and which browser will support them. There are few sites that will give you good answers. The lastest one is: html5please.us and other good sources are caniuse.com which include mobile browsers as well and mobilehtml5.org that is all about capability for mobile browsers.

JavaScript MVC frameworks

There is a new kid on the block - Thorax I like that fact that it is an opinionated backbone application framework. It is a combination of several tools:

Backbone – the core framework
Underscore – JavaScript utility belt with you
Zepto – jQuery DOM goodness for mobile
Handlebars – mustache for movember
Stylus – Good and clean CSS experience
Lumbar – packaging utility

Another framework that is worth the time to look into is: emberjs and Trello tech stack that is coming from the great dudes of ‘Fog Creek’.

If you wish to check what other options you have today - I would go to this site and check some of the most popular MVC framework that are out there.

Work and share javascript online

Jsbin.com
jsfiddle.net
Google code playground - which include some good examples of Google and JavaScript APIs.

I also found myself using Simple JSON viewer in cases you wish to find out a specific parameter in a large JSON object.

Playing with CSS3

Nice html5 app to play with gradients and of course http://css3please.com that let you tune your styles online.
http://westciv.com/tools/ - Great collection of tools to improve your CSS/CSS3 capabilities.
http://pageblox.com/ – A tool to help you build your next grid online.
Examples for CSS3 usage: CSS3 Patterns Gallery
CSS3 Gradient Generator - The CSS3 Gradient Generator is a showcase for the power of CSS gradients.
CSS Gradient Generator - a powerful Photoshop-like CSS gradient editor from ColorZilla.

Libraries for Fonts

Google Web Fonts API – Google Web Fonts makes web fonts quick and easy to use for everyone, including professional designers and developers. We believe that there should not be any barriers to making great websites.
TypeKit – Simple, bulletproof, standards compliant, accessible, and totally legal fonts for the web.

Offline Libraries & Frameworks

ManifestR – a bookmarklet for creating an AppCache manifest file.
LawnChair – a library that provides a lightweight, adaptive, simple and elegant persistence solution.

For Mac Web Developers

LiveReload monitors changes in the file system. As soon as you save a file, it is preprocessed as needed, and the browser is refreshed. When you change a CSS file or an image, the browser is updated instantly without reloading the page.
CodeKit automatically compiles Less, Sass, Stylus & CoffeeScript files. It effortlessly combines, minifies and error-checks Javascript. It even optimizes images, auto-reloads your browser and lets you use the same files across many projects.

Mobile web development – Some good reads

The mobile web application tech stack - Good post by @borismus on the best tools today for developing mobile web app.
Rethinking the mobile web: a good presentation which take a slightly different slant on the responsive web design ethos for mobile devices.
CSS media query for mobile is fool’s gold - Cloud Four’s article sets the record straight regarding claims that responsive web design is perfect for producing mobile-optimised websites.

It is far from being a full list – just a beach-head to start have a source for some tools that will make you more productive.

How to work with your closest client : Your Family

2012-02-16T23:36:00.000+05:30

Doing freelance design work for a family member or friend can be super stressful. While some freelancers have no problem working with family, others would say that family projects are miserable.

There are times, though, when you can’t turn down a friend or family member without causing a major rift. This post provides some pointers to help make friend and family projects go more smoothly.

Ten Tips for Working with Friends and Family

So, you find yourself working for a friend or family member, but you don’t want the project to deteriorate into bickering and fighting. What can you do to keep the project running smoothly and protect your nerves at the same time?

Depending on your family member or friend, some disagreement may be inevitable. If you don’t ordinarily get along well with them, you can’t expect working with them on a design project to be any different. But there are some things you can do to minimize the damage:

Manage expectations. Explain what you do and how you do it to your family member. Show them some of your samples so that they have an idea of what to expect. Give them a realistic timeframe. Don’t promise more than you can deliver.
Set limits. While you are managing your friend’s expectations, be sure to explain what you will not do for them. If you don’t work evenings or weekends, let them know that. Make sure that the scope of the project is clearly defined.
Listen. Listening is a vital part of any freelancer/client relationship, but it’s especially important when you also have a personal relationship with your client. Don’t let familiarity get in the way of hearing what the client is really saying.
Communicate in writing. Even if your discussion with your relative is verbal, write down the main points and email them to your friend or family member. Ask them to review the email. It will be much easier to remind them later of what you agreed to if it is in writing.
Pick a project leader. Avoid dealing with a group of friends or family members. Too many bosses always spells trouble. If your project is for more than one friend or family member, make sure only one of them is in charge. Explain that this is how most projects work.
Stay cool. Nobody can punch your buttons better than a friend or family member. However, the best way to preserve both your personal and professional relationship is to stay calm. If you feel yourself getting angry or upset, give yourself some space until you can recover.
Charge a fee. If you can, charge your normal rate. If you feel compelled to work for free because of the personal relationship, at least tell them how much you would normally charge. This will help them to see that your time is valuable.
Don’t gossip. Even if your friends and family members are ordinarily your support group that you talk to when projects go bad, don’t turn to them about this project. Don’t complain about one friend or family member to another friend or family member.
Separate work. As much as possible, keep work and your personal life separate. No working during family get togethers. Work on the project only during business hours. Don’t let them push you into working on their project 24/7 just because you are related.
Do your best work. Above all, once you accept a project from them, your friend or family member becomes a client. It is still important to have a happy client. Do your usual good work for them. A satisfied friend or family member may become one of your best references.

The Future Of Screen Typography Is In Your Hands

2012-02-15T01:41:00.000+05:30

We do more reading on the screen today than we did even a year ago. If we are ever to have a golden age of reading on the screen, this might be the start of it.

Tablets, Nooks and Kindles make buying a book or magazine for the screen almost unavoidable. With smartphones, we carry our reading material with us and enjoy instant Web access, enabling the reading experience to flow smoothly from one device to another. And those devices probably have stunning HD reader-friendly screens. Throw in companion services like Readmill and 24symbols, which allow us to share our reading experiences, and we have perfect screen-based access to all aspects of the written word.

So, why isn’t Web and screen typography keeping up?

Good Typography Cannot Be Handcrafted Anymore

In the past, typography was viewed as living only when it reached paper. Once a publication was edited, typeset and printed, it was done. Nothing changed after that. Good typography and readability were the result of skilled typesetters and designers.

Today, typography exists not only on paper but on a multitude of screens. It is subject to many unknown and fluctuating parameters, such as operating system, system fonts, the device and screen itself, the viewport and more. Our experience of typography today changes based on how the page is rendered, because typesetting happens in the browser.

In all of this, the browser is probably the most important part of the screen typography equation. Ironically, the lack of support in modern browsers is the single biggest hurdle to good Web typography.

Type-as-service providers are offering an alternative, with an increasing number of fonts that are fairly cheap and easy for us designers to use when typesetting text. But they, too, want better support of Web typography.

Identifying What’s Missing

Let’s look at some of the basic things that are missing from most, if not all, screen-reading experiences. When we say basic, we mean the things that you read and benefit from whenever you look at a book or magazine on paper or screen.

Kerning and spacing of individual characters;
Basic ligatures (fi, fl)
Other ligatures (fj, ffi, ffl, ffj and more);
Lining and old-style numerals;
True small-caps;
Replacing uppercase with small-caps for abbreviations;
Superscripted symbols such as © and ™;
Language-based quotation marks;
Correct replacement of en and em dashes, and the spacing around them;
Spacing of ! ( ) [ ] / ; :.

Doesn’t seem like much. Except that it is. The elements in this list are some of the things that help us read, process and understand information. They represent in many ways the difference between how a soulless machine would relate to text and how thinking, organic humans do it.

Those of you who were around during the desktop publishing boom might see similarities. In 1999, QuarkXPress did not support OpenType, InDesign was just born, and you had to use “expert” cuts of fonts to be able to work with small-caps and old-style numerals. So, we had to create workarounds for micro-typography — such as Apple-Script frameworks for QuarkXPress, where the script traversed documents and isolated hyphens, dashes, ligatures and small-caps abbreviations, replacing them with the correct typographical equivalents.

In many ways, 2012 is the new 1999. We have the freedom to work with any font we like via the @font-face selector. But our main tool, the browser, does not have any OpenType features to speak of. We have to create workarounds.

Can we use the same type of solution that we used back in the old days of print?

We say yes.

Time to Fix the Problem

We researched existing JavaScript libraries and found a ton of great stuff. But none focused on micro-typography as a whole. When we started the project, we laid out five clear goals:

Correct micro-typography, including as many of the elements in the list above as possible;
Degrades so that devices without @font-face or JavaScript support are not negatively affected;
OS independence;
Browser independence;
Correct markup;

We named the project OpenTypography, and we named the solution Typesetter.js.

JavaScript and @font-face and styles disabled.

JavaScript disabled.

JavaScript enabled and @font-face-enhanced Web typography.

Typesetter.js

Typesetter.js has two ingredients: a JavaScript and a custom font file

The JavaScript traverses the DOM, finding and replacing things like quotation marks, ligatures, en and em dashes, ellipses and more. It also finds ©, ®, ™ and wraps them in sup tags.

Most importantly, it finds uppercase abbreviations and wraps them in abbr tags, giving us true small-caps. This is possible thanks to a bit of CSS and the services of font-on-demand houses such as Fontdeck and Typekit.

Finding, replacing and wrapping.

Here is a rundown of how Typesetter.js works.

1. The JavaScript

The code is divided into two parts, giving you the option to use the small-caps replacement. But let’s start by looking at how the small-caps replacement works.

Here is the sample HTML that we will use to explain what the script actually does:

<p class="typo">The fine details of screen typography can be improved with JS-scripts and CSS.</p>

<p class="typo">That is the goal of "Typesetter.js" — an open-source solution by Andreas Carlsson and Jaan Orvet © 2011</p>

Our sample text rendered with Georgia and browser-native typographic features.

In this text, we want to find all-uppercase words.

The code starts by getting all elements of a user-chosen class, in this case .typo. These elements are stored in an array.

mainArray[0] = 'The fine details of screen typography can be improved with JS-scripts and CSS.';
mainArray[1] = 'That is the goal of "Typesetter.js" — an open-source solution by Andreas Carlsson and Jaan Orvet © 2011';

Each array element is then looped one at a time and split into a sub-array containing each word as a string.

subArray[0] = 'The';
subArray[1] = 'fine';
subArray[2] = 'details';
subArray[3] = 'of';
subArray[4] = 'screen';
subArray[5] = 'typography';
subArray[6] = 'can';
subArray[7] = 'be';
subArray[8] = 'improved';
subArray[9] = 'with';
subArray[10] = 'JS-scripts';
subArray[11] = 'and';
subArray[12] = 'CSS.';

Each item in the sub-array is tested to see whether the character count of the word and the count of the uppercase letters (ASCII values between 65 and 90) are equal. If so, the word is treated as an uppercase abbreviation.

The test actually checks the first and last character of the sub-array item. If they are uppercase, then it is fair to assume that the whole word is an uppercase abbreviation, and then we would run a more specific test. Here is what the script returns from our sample text:

“The” = false (do not run specific test)
“details” = false (do not run specific test)
“Andreas” = false (do not run specific test)
“CSS.” = true (run specific test)
“JS-scripts” = true (run specific test)

As you can see, the test also spots uppercase words when they are used with a hyphen or have an trailing period.

Our special uppercase test creates an index array that holds the indexes of the uppercase words (i.e. it identifies where in the full sentence they occur). After the whole sub-array is tested, we would have the sub-array and the index array containing the all-uppercase indexes.

indexArray[0] = '10';
indexArray[1] = '12';

Now that we know where all of the uppercase words are in the string (i.e. sentence), we can prepare them for small-caps replacement.

Small-caps replacement is done by extracting the word, converting the letters to lowercase, wrapping the whole word in an abbr tag and inserting it into the sub-array again.

subArray[0] = 'The';
subArray[1] = 'fine';
subArray[2] = 'details';
subArray[3] = 'of';
subArray[4] = 'screen';
subArray[5] = 'typography';
subArray[6] = 'can';
subArray[7] = 'be';
subArray[8] = 'improved';
subArray[9] = 'with';
subArray[10] = 'js-scripts';
subArray[11] = 'and';
subArray[12] = 'css.';

Now we only need to convert that array into a string and replace the original HTML element with the new small-caps-ified HTML element.

Before:

<p class="typo">The fine details of screen typography can be improved with JS-scripts and CSS.</p>

<p class="typo">That is the goal of "Typesetter.js" — an open-source solution by Andreas Carlsson and Jaan Orvet © 2011</p>

After:

<p class="typo">The fine details of screen typography can be improved with js-scripts and css.</p>

<p class="typo">That is the goal of "Typesetter.js" — an open-source solution by Andreas Carlsson and Jaan Orvet © 2011</p>

Our sample text set with Tanger Serif from Typolar, using the @font-face rule. Uppercase words are now wrapped in abbr tags.

Nice and neat. Now for the second part of the script, the one that replaces quotation marks, ligatures, en and em dashes, and ellipses; renders characters such as © in superscript; and converts numerals to old style by wrapping them in a user-defined class.

The code is fairly self-explanatory:

var charReplacements = function() {

/* Quotationmarks
‹ = ‹
› = ›
« = «
» = »
‘ = ‘
’ = ’
“ = “
” = ”
*/

var quoteCharClose = "»";
var quoteCharOpen = "«";
var triggerID = "#display";
var smallcapsClass = "old-style"

$(triggerID).each(function() {
$(this).find('*').each(function() {
 if (($(this).html()) != 0) {
  if (($(this).find('img').length) === 0) {
  // Performs replaces on any element that is not an

$(this).html( $(this).html().replace(/(\.\.\.(\.)?)|(\.\s\.\s(\.\s)?|(\.\.(\.)?))/g, "…"));
  // Finds and replaces .. | ... | .... with an elipsis

  $(this).html( $(this).html().replace(/fl/g, "ﬂ"));
  // Replaces fl with ligature

  $(this).html( $(this).html().replace(/fi/g, "ﬁ"));
  // Replaces fi with ligature

  $(this).html( $(this).html().replace(/\s-\s/g, " ‒ "));
  // Replaces | space en-dash space | with: | space em-dash space |

      $(this).html( $(this).html().replace(/"([\s\.\,])/g, quoteCharClose + "$1"));
  // Replaces | " space | with | » space |

  $(this).html( $(this).html().replace(/\s"/g, " " +  quoteCharOpen));
  // Replaces | space " | with | space « |

  $(this).html( $(this).html().replace(/(\d+)(?=((?!).)*(-tag with the .old-style-class but ignores digits within a a-tag. Read full explanation here http://www.phpbuilder.com/board/archive/index.php/t-10221442.html

  if ( (($(this).children().length) === 0) || ($('this:contains("u00a9")')) ) {

   $(this).html( $(this).html().replace(/\u00a9/g, "

^©

") );
   // Superscripts (c)

   $(this).html( $(this).html().replace(/\u00ae/g, "

^®

") );
   // Superscripts (R)
  };
 };
   };

});
});
};

Most of the typographic details in the script are declared in the variables at the beginning. This is the beginning of a “settings” type of solution that we are working towards building.

”Settings” is a pretty important feature because typographic rules change depending on the language; for example, quotation marks and the spacing of em dashes. English, French and German each use different quotation marks, so the designer needs to be able to easily change the typographic settings.

Now we have pretty decent typography in our example:

<p class="typo">The fine details of screen typography can be improved with js-scripts and css.</p>

<p class="typo">That is the goal of «Typesetter.js» — an open-source solution by Andreas Carlsson and Jaan Orvet

^©

2011</p>

Our sample text with much better micro-typography than what the browser supports natively.

We have covered a lot, but the most important part is still to come!

2. The Custom Font File

Let’s move on to the font file itself.

Putting Small-Caps and Old-Style Numerals in Place

Our text is now wrapped in classes; we can use CSS to set it in small-caps and old-style numerals. Since no browser supports OpenType, we cannot use the regular font-variant: small-caps rule, because this would only shrink the uppercase letters, resulting in thinner and lighter characters.

The font-variant: small-caps rule merely shrinks uppercase letters, resulting in thinner and lighter characters. To get real small-caps, we have to use our custom subsetted font file.

The font file we need is a subset of the regular cut; in it, the uppercase characters have been replaced with small-caps characters, and the lining numerals have been replaced with old-style numerals. (Remember the days of “expert set fonts”? It’s a bit like that. If you don’t remember, you’re better off for it.)

We can now specify in our CSS files to use the subset for abbr tags. This will give us true small-caps on the Web and allow us to choose between old-style and lining numerals in our text.

abbr {
   font-family: "Tanger Serif Expert", Cambria, Georgia, serif;
   letter-spacing: 0.15em;
   text-transform: lowercase;
   font-variant: small-caps;
   font-weight: 650;
}

Get the Font File

Fontdeck supports the OpenTypography project by kindly serving subsetted fonts in addition to its main fonts.

Other type services and foundries make subsets available as well. We keep an updated list with examples atOpenTypography.

Create Your Own Font File

If you have experience working with fonts, then creating your own subsetted font files is fairly straightforward.

Open the regular cut in your favorite font editor. Copy the small-caps glyphs, and paste them where the uppercase and lowercase glyphs are. Copy the old-style numerals to where the lining numerals are. Once this is done, you only have to generate a new font file and convert it to all the required Web font formats: TTF, OTF, WOFF, EOT, SVG.

You can easily create your own subsetted custom font file. Just replace uppercase and lowercase glyphs with the small-caps versions and the lining numerals with the old-style ones.

Now you have your own custom Web font ready to be used with Typesetter.js

But be sure to check the license to make sure you are permitted to adjust the font file and to embed it via the @font-face selector.

A Beginner’s Guide To jQuery-Based JSON API Clients

2012-02-15T01:36:00.000+05:30

Are you fascinated by dynamic data? Do you go green with envy when you see tweets pulled magically into websites? Trust me, I’ve been there.

The goal of today’s tutorial is to create a simple Web app for grabbing movie posters from TMDb. We’ll use jQuery and the user’s input to query a JSON-based API and deal with the returned data appropriately.

I hope to convince you that APIs aren’t scary and that most of the time they can be a developer’s best friend.

Progressive And Responsive Navigation By Jeremy Hixon

2012-02-15T01:32:00.000+05:30

Developing for the Web can be a difficult yet rewarding job. Given the number of browsers across the number of platforms, it can sometimes be a bit overwhelming. But if we start coding with a little forethought and apply the principles of progressive enhancement from the beginning and apply some responsive practices at the end, we can easily accommodate for less-capable browsers and reward those with modern browsers in both desktop and mobile environments.

Read More @ Smashing Magazine

Tutorial : How to install django on App engine

2012-02-15T00:52:00.000+05:30

It took me three day to completely work on the making django run on google app engine and thats awesome.

And the Final Message for which i'm excited about is

It works!
Your Django-nonrel installation is working fine. Now go and build something useful with it. :)
Also, make sure you follow the Django-nonrel & webdev blog, so you don't miss any new features and improvements.
If you're new to Django you should take a look at the Django documentation and the Django book. You'll also find djangosnippets very useful.
If you search for reusable apps that work with Django-nonrel here's a list to get you started:

django-mediagenerator: Combines and compresses your JS and CSS files

django-dbindexer: Adds extra DB features (e.g., __iexact, JOINs, etc.) beyond the native DB API

nonrel-search: A simple full-text search engine for App Engine and other non-relational DBs

django-filetransfers: Generic API for file uploads/downloads (e.g. via App Engine Blobstore)

allbuttonspressed: The simple CMS/blog that powers the Django-nonrel website

...and our other projects...

Finally, take a look at the apps listed on Django Packages. Many simple Django apps (e.g., django-registration) should work unmodified. If you want to use django-debug-toolbar you need to disable the SQLDebugPanel in your settings.
Powered by Django-nonrel

That is really awesome . How did i do it ? all by one link i mean two links

djangoappengine - Django App Engine backends (DB, email, etc.)

Running Pure Django Projects on Google App Engine

The awesome thing i find you find links one in one pages.

And BTW the tutorial is in this link : djangoappengine - Django App Engine backends (DB, email, etc.)

Using Google App Engine

2012-02-13T23:23:00.000+05:30

These are supporting materials for the O'Reilly book titled Using Google App Engine. This book is aimed at people who want to gain skill in web programming in general and the Google App Engine. The book has been used to support many beginning web programming courses.

Installing Google App Engine

Macintosh: (Handout, YouTube, Download Screencast)
Windows: (Handout, YouTube, Download Screencast)

You can download the Sample Applications from the book to use as guidance for your projects.

Chapter 1 - Programming on the Web (Slides, Printable Slides, Lecture Audio)
Chapter 2 - HTML and CSS
- Hypertext Markup Language - (Slides, Printable Slides, Lecture Audio)
- Cascading Style Sheets (Slides, Printable Slides, Lecture Audio)
Chapter 3 - Python (Slides, Printable Slides, Lecture Audio Part 1, Lecture Audio Part 2)
Chapter 4 - Hypertext Transport Protocol (HTTP) (Slides, Printable Slides, Lecture Audio Part 1, Lecture Audio Part 2)
Chapter 5 - Web Applications and Python Objects
- Web Applications (Slides, Printable Slides, Lecture Audio)
- Python Objects (Reading Chapter 3) (Slides, Printable Slides, Lecture Audio)
Chapter 6 - Templates
- Templates (Slides, Printable Slides, Lecture Audio Part 1, Lecture Audio Part 2)
- The Login Application (Slides, Printable Slides, Lecture Audio)
Chapter 7 - Cookies and Session
- Cookies and Session (Slides, Printable Slides, Lecture Audio)
- The Login Application using Sessions (Slides, Printable Slides, Lecture Audio)
Chapter 8 - Datastore
- Datastore (Slides, Printable Slides, Lecture Audio Part 1, Lecture Audio Part 2)
- Chat Application (ae-11-chat) (Screencast)
Chapter 9 - JavaScript and Ajax
- Lecture (Slides, Printable Slides, Lecture Audio Part 1, Lecture Audio Part 2)
- Ajax Chat Application (ae-12-ajax) (Screencast)
Chapter 10 - Going into Production (Slides, Printable Slides, Lecture Audio)
Chapter 11: Simple Session Implementation: (Utility Code and Documentation)

What are the best productivity tools for entrepreneurs?

2012-02-13T23:00:00.000+05:30

Software / Web

Dropbox (most popular answer, others suggested Box.net as an alternative)
Evernote
Gmail
Google Chrome
Google Docs
LinkedIn
Mailchimp
Mindmaps (Freemind or Mindmanager)
Skype
Wunderlist
Xobni
Expensify
Asana
Basecamp
KeyRocket (keyboard shortcut trainer)
Helpjuice.com (knowledge base)
Remember The Milk
Redmine

Real World

Whiteboards
Smartphone
Moleskin notebook
Skinny Pen
GoToMeeting or equivalent

PS3 Games development

2012-02-11T21:21:00.000+05:30

This is the current state of affairs with indie-type PS3 programming that I know of.

There is no equivalent to what Microsoft has with XNA, a framework that allows you to create games for the XBox 360 (albeit in C# and .NET, not with C++ and all that).
Sony has a free game engine called PhyreEngine, but it's only available to its developer network and schools with an agreement with Sony.
No public SDKs / documentation for specifically PS3 programming (complete with GPU programming and such) that I encountered.
Most resources on the net will discuss Cell programming, but not the whole package.
- MIT's PS3 Lectures
- Cell programming
Access to even becoming a PSN developer requires you to go through approval process (and maybe a cost of $1200), and the approval process looks at your finances, business statements, and experience in industry
Back when you could still load Linux on the PS3, you could use the Linux environment to program for the PS3, except that you did not have access to the RSX GPU.
In short: you likely have to pay to play
Edit: Unity3d can be used to develop for PS3 now too, but since I don't have access to its documentation, I don't know how it really works with loading on the PS3. I also think to get the PS3 functionality, you need to buy the Pro license which costs $1500/seat. And more info here:http://answers.unity3d.com/questions/18628/unity-to-ps3-or-360

After 6 years doing Flex, am I moving to HTML5? by João Saleiro

2012-02-07T20:50:00.000+05:30

After 6 years doing Flex, am I moving to HTML5?

Short answer: no. But I'm investing in HTML5.
(really) Long answer: see below.

After returning from the Flex Summit, many people have contacted me asking what was going to happen with Flex and if I was going to "migrate" our projects (like http://airgile.com ) and services to HTML5. After plenty of exchanged emails and dozens of long talks, I decided to write down and share some notes of my first steps in the HTML5 world regarding the development of Enterprise RIAs (or not). These notes are not organized, they have typos and - as I said above - they are only my first steps so more experienced people might (and will) prove me wrong in some topics.

Background

I founded Webfuel in 2004 and since then we've specialized in building long-term (> 6 months) enterprise-grade RIAs that had to scale well and be prepared for constantly changing requirements with a low cost in maintainability, while simultaneously providing a top-notch user experience. We've managed to offer our services comfortably with a very limited number of resources and small development teams (3-5 persons per project), much thanks to the way we leveraged existing knowledge on Software Engineering and applied it to our platform of choice - Adobe Flex (now fortunately called Apache Flex).
Our decision was purely technical and we have never regretted our choice, until it got badly affected by the bad PR around the Flash platform.

Worse PR ever in November 2011

The Flash platform was already in bad shape, much thanks to one year of chaotic PR and there were already some inconsistent signs from Adobe hinting what was going to happen. While disappointed, I was not very surprised when all hell broke loose in November 2011 with Adobe destroying the very last credibility that Flash still had, directly affecting Flex, our businesses and careers. Long story short, Adobe wasn't able to monetize the Flash Platform and the top managers who don't really care or understand its power simply decided to put the money where their mouth was: HTML5. I happen to strongly agree with the move on investing in HTML5, but they could and should have done it without destroying (the perception of) Flash. Especially because in the meantime it had turned into the platform of choice for Enterprise Development.

In December '11 Adobe has donated Flex to Apache. While this might end up in being the best thing that could happen to Flex, the initial reaction from the Enterprise was that Adobe was getting rid of Flex. Like someone said during the Flex Summit - "it seems to me that Adobe has built the best platform for creating enterprise-grade applications by accident". Adobe understands design; creativity; marketing; publishing; Adobe doesn't seem to understand Enterprise. Example #1: all corporate companies I worked with in the last 6 years complained about the lack decent support from Adobe and they were willing to pay big money. Example #2: the pricing of LCDS.

Did Adobe kill Flex? No! A technology doesn't have a heart attack and drops dead on the floor. Flex is still alive and the reasons why we chose it are still perfectly valid. Flex didn't get worse suddenly - it's still the same robust platform for enterprise RIA development.
What was destroyed was the perception of the Flash Platform. And the perception is what matters on business. You can have the best product of the world, but if people believe it's bad they won't buy it (and they'll even be happy on telling everyone how much your product - that they never used - sucks). But if they think it's good - even if it actually sucks - they'll probably buy it (and complain later). Perception. That's what sells. Perception.

Will the perception around Apache Flex ( http://incubator.apache.org/flex/ ) improve? Most likely, yes. In 9 days, there were more than 1.4 thousand emails exchanged on the Flex Mailing List (http://incubator.apache.org/flex/mailing-lists.html ) ! It's pretty impressive the number of people that are now involved in pushing Flex forward and this number will most likely keep rising. But Apache Flex still relies (or, at least for now) on the Flash Platform and I'm not seeing the bad perception on the Flash Player changing in a near future. Of course there's still AIR, but what concerns me are browser applications.

We are desktop-developers-working-on-the-web

An important side note, is that I see Webfuel as a team of desktop developers working on the web. In other words, we use desktop development paradigms, best-practices and design patterns borrowed from the JAVA world and we've applied them to build applications that happen to run inside the browser. Our work consists normally in building at least two loosely coupled applications, connected by an RPC API: a client application (running inside the web-browser) and a server application that only exposes services and is not aware of the client application.

Most Flex developers out there think on themselves as web-developers, but in most cases the mindset of a Flex developer is closer to a desktop developer than to a web developer. IMHO, this is the single-most-important reason on why we, Flex developers, dislike so much the "normal" web development approaches.
We work with "views", web developers work with "documents". We do old-school MVC, DI, loosely coupled approaches, dependency management, RPC, code coverage, continuous integration [...], and when we're forced to do web-development these are the first concepts that we try to investigate and replicate... before we get frustrated and enter in "denial".
To be good at typical web-development, we have to change our mindset.

Is "HTML5" ready?

According to Twitter, online magazines, blogs, Apple, Microsoft and even Adobe, HTML5 is the silver-bullet for everything. It can be used to build websites, webapps, games, software, mobile applications, doing laundry and cooking. The focus is all on HTML5 right now. Is it the right moment to use it?

From the point of view of a web-developer - of course it is!!! For a typical web-developer, HTML5 means more tools, more power and much better cross-browser compatibility than what they had before. If you're working on the web, HTML5 and the storm of JS frameworks is simply the best thing that has happened to the web since.... humm... Flash. :o) Bottom line, HTML5 is for sure a giant step forward.

From the point of view of a desktop-developer-working-on-the-web - hell no! WTF? We work on the enterprise and enterprise means stability. We can't afford to have too many moving pieces all the time. We can't afford to deal with un-structured languages. If you've used Flash or Flex for the last 5 years, you'll feel that in HTML5 there's nothing new or better than what you already have. Worse, you'll feel that there still are hundreds of needed capabilities and tools missing. Exception to the rule, happens if you're targeting the browser of Mobile devices, where HTML5 is king.
It's quite understandable that a Flex developer feels frustrated. You feel you're going backwards 4 or 5 years. It happens that, as Ted Patrick stated ( http://tedpatrick.com/2011/11/12/living-in-the-future/ ) , we were living in the future...

Ignore the PR shit storm. Ignore fanboys. Choose the right tools. Ask the right questions to the right developers

People like to take sides. If I like and use something, for sure it's because it's the best thing ever and all the rest sucks or is dead. That's how it works for most fanboys.
Newsflash: if 10.000 persons say that something sucks, it doesn't really mean that it really sucks. It means that they believe it sucks. It's like believing in a religion - each follower defends his religion, but which one is the "right" religion (or, is there a "right" religion)? The irony is that developers should be pragmatic people but we often see them becoming fanatic about their technology choices. "Infidel, infidel", they yell with their pitchforks in the air when you say the name of a "competitor" technology. WTF?

For me, technologies are just tools. Obviously I would like to have as many good tools as possible so I can be able to choose the right one for each task. Be it Flex, HTML5, Javascript, Actionscript, JAVA, PHP, whatever.

Bottom line: ignore the PR shit storm. Ignore fanboys. Choose your tools based on logic. You wouldn't choose a hammer to cut wood, would you?

Last year, when I started digging seriously into Javascript, I had many questions. I took for granted that someone who defends a technology with so much conviction, probably understands it pretty well. So I placed several questions to these guys expecting to learn new stuff and understand their best practices. It happens that I haven't learnt shit. It was like if me and they were from different planets, speaking different languages. Even similar words have different meanings (their MVC is not our MVC. their dependency management is not our dependency management... etc).

I've sent a couple of emails to mailing lists of HTML5 and JS development asking people what they were using for MVC, IoC, Unit Testing, Code Coverage, Compiling, Continuous Integration, etc, etc. The answers were like "WTF dude, IoC? What are you talking about?". I now know that I was doing the wrong questions, as you'll see below.

Since I couldn't get (or understand) answers from the gurus of the JS world, I started trying to find people who were doing both large-scale Actionscript and Javascript. They would understand me. :o) It happens that there aren't many and most of them were more or less at the same point I was. The best single advice I got was: "accept web dev for what it is and don't try to change it. Don't do RIAs. Do simple web development. Then improve.". Good advice!.

Redefining our focus

As I said above, technology-wise, Flex is still perfectly valid. But it's perception is at its lowest level and clients are quite confused and started asking us to use HTML5 to build the same type of solutions we were building with Flex.

So we had to rethink our business, and considering our desktop-developers-working-on-the-web mindset, we've decided to:

1- return to our roots: desktop development. That's what we're good at and we can still keep using Flex to build AIR applications, either for the desktop or mobile. Since we can embed the AIR runtime, those applications will be future-proof to any other crazy-game-changing decisions made by Adobe.
2- increase our investment in developing (simple) HTML(5) webapps, while accepting the web for what it is: broken. In other words, we have to be humble about what we can provide on the web. It's too hard and expensive to build the same type of applications we were building, so we're starting with just simple webapps.

We won't be accepting huge enterprise-grade projects if they're meant to be built in HTML(5). This is actually the hardest problem to manage. There are expectations from clients. They've gotten used to our beautiful RIA applications, with almost no waiting times, with beautiful and pixel-perfect interactive user interfaces. And now they want the same, but in HTML5, because Flash is "dead" and HTML5 will also run on their Mobile devices (all of them), faster and without consuming battery. At least, it's what they heard.... The solution for this problem is to say "No, we are not ready to develop it in HTML5". We'll be restricting our development to simpler web-apps, until we feel that we (and the web) are ready.

First steps in JS and HTML5

During 2011, I've read A LOT about JS frameworks, libraries, approaches, etc. Sometimes after finishing reading something, it was already outdated and a better library was available.

My first impression was that most docs were "meh": in most cases you have an excellent "Getting Started" guide, but as soon you start getting your hands dirty in more complicated scenarios, things start falling apart and you'll see none or outdated advanced documentation.

Another trend that I hated in my readings was the lack of objectivity: instead of the typical website and docs saying "this framework does A,B,C,D" , I saw a lot of "THIS IS THA MOTHA-FUCKA FRAMEWORK THAT WILL SAVE UR LIFE!", "MEGA-HYPA-SHIZZLA-FRAMEWORK". This type of communication felt weird and suspicious to me until I got used to it.

I've also seen several frameworks being dropped in favor of others, which was actually what scared me the most. I felt insecure choosing the "right" libs and frameworks, so most choices I did at start were the safe ones, as you'll see below.

Another irony was that most of the JS frameworks exist to overcome the limitations of the web development (normally, the crossbrowser issues). Coming from an environment where a framework tries to abstract application concepts, it felt weird to me to use frameworks to abstract technical limitations. Today, I've learnt to enjoy and welcome these frameworks. Accept them for what they are, because the technical limitations actually exist and without those frameworks you're screwed.

In October 2011, I decided to start a medium sized real-life HTML5 webapp with a partner company, so we could test the knowledge I gathered. (A medium-sized project in the point of view of a web-developer; as a desktop-developer I see it as simple stuff #notBeingHumble ). I've allocated two developers to the project - with myself being one of them. Below are the choices we made.

Knockout.js

Despite having read about Backbone, Spine and other more complex frameworks, I've decided to start small and simple with Knockout.JS . I just wanted simple data-binding to start with, so I could get some separation between the data model and the view. Later, when we were more experienced, I would re-evaluate the choice of the framework and choose between Backbone, Spine, or another.

My choice has proven to be worthy since Knockout is actually quite simple - but far more complicated and intrusive than the ultra-easy and powerful binding we're used to in Flex.

The documentation of Knockout is quite good, with plenty of tutorials available. On Google you won't find as many resources on Knockout as you would like, but fortunately the website covers most of the important topics. The mailing list is pretty good, despite not being as active as the MLs I'm used to in the Flex world with dozens or hundreds of experts. Anyway, in the Knockout ML, there were always one or two people kind enough to point you in the right direction, which is great.

jQuery

I had already a good impression on jQuery, but even still it turned up to be even better than what I expected. jQuery not only hides a lot of the crossbrowser issues - not all -, but also boosts up a lot your productivity with dozens of shortcut functions to most of the stuff people normally need to do on the web. Use it (can you live without it?).

SaaS

Managing CSS can easily turn into a pain especially if you need to do many changes to an existing stylesheet with hundreds of CSS declarations. When Googling for best practices, I met SaaS. SaaS is actually pretty simple: it lets you define CSS stylesheets with declaration hierarchy, variables and mathematic expressions, saving them on a scss file. Then you start a command line task that listens for changes in your scss file and converts it to a CSS file on the fly.

I haven't looked at Less, so I don't really know which one is better.

Lab.JS

I also discovered (the hard way) the pain that it can be to manage dependencies in Javascript. I was used to having all class definitions packaged for me in a single SWF and the Flash VM would take care of embedding and managing dependencies for me (pretty most like all bytecode VMs do). In the Javascript world, there's nothing taking care of this for you. You start by setting in the HTML file the location of the scripts needed, but then you cannot control the order they are loaded and run. So you can be calling a function myFunction() in fileB.js that was defined in fileA.js that was not loaded yet - resulting in errors.

I've chosen Lab.JS to solve the issue of loading dependencies on the right order. I'm also making sure that any initialization code only runs AFTER all the needed files are loaded.

I've found a problem with Lab.JS: if your code throws exceptions, they will be swallowed by the library and nothing happens. My workaround (read: ugly hack) was to do a " setTimeout(initialize, 1); " after the scripts are loaded. This way exceptions are now caught by the browser, as you would expect.

IDEs

This was one of the biggest disappointments in the beginning. The biggest problem of JS is that due to its dynamic nature it's hard to be tooled around. For building large scale complex systems, especially in a team environment, I needed good refactoring capabilities. It happens that refactoring doesn't exist in the IDEs I tried.
Ok, there is something called "rename" in WebStorm but it works for very simple cases and I've seen it resulting in unexpected results (so I always use the "preview").

Flash Builder is a complete beast (in a good sense). I've seen many people ranting on Flash Builder and even I had some disappointments a couple of years ago. But after FB 4 it just got awesome, with its serious refactoring capabilities, find usages, metadata completion, autocomplete, inline docs, content assist, etc. Most of the best tricks from the JAVA world are available on FB. If you expect to find those in JS editors, I have bad news for you.

I've started with Aptana. It's free. It's based on Eclipse, so I felt at home at least with the shortcuts and the structure of the IDE, but with a black editor (wtf? is this the "fashion-color" for supa-dupa-web-developers?). Anyway, after two months I got tired of it. I couldn't do refactoring. I couldn't jump properly to a function definition with CTRL+click (and this was REALLY annoying). It didn't have decent auto-complete. I've tried making the debugging work but it only worked properly 15% of the time.

Then I've decided to give PHPStorm a try - which is the same as WebStorm, but also supports PHP. At first, I was lost: I couldn't find half of the stuff I needed. After one day, I was pretty comfortable with it and now I feel it's actually pretty well built. Ok, it's NOT Eclipse, but even still it's quite powerful. What those guys did was to implement really well the things you use most while developing and packaged all of them in a clean and objective interface. Kudos to JetBrains (http://www.jetbrains.com/ )!
In PHPStorm, refactoring "sorta" works in simple scenarios. If you complicate too much (like when you try to mimic packaging for your objects), it won't work. Click and jump to a function definition works. Debugging... works!! Autocomplete works a lot better than I expected. Actually, it works quite well. The catch: comparing to Aptana, it's not free.
Coming from Flash Builder, will you be happy with PHPStorm? No. But currently it seems to me that it is probably the best IDE for Web development.

Debugging

I feel ashamed to say that I couldn't debug properly during the first two to three weeks. Every tool I tried didn't work as expected. It happens I was using the wrong tools, browsers and approaches.
I ended up using the debugging capabilities of both Firebug (in Firefox!) and PHPStorm. Firebug is also pretty helpful to inspect the DOM of the document, something you'll be doing every 5 minutes. Both Firebug and PHPStorm allow you to place a breakpoint in JS code and then run your code step by step, as expected. PHPStorm looks more comfortable to me, also because it's where I'm writing my code.
Bottom line: If your debugging is not working, don't blame JS: you're simply using the wrong tools.

Javascript

This was probably my biggest pain point. I'll start with the conclusions: accept Javascript for what it is and don't try to mimic your common OOP techniques and classes. There.are.no.real.classes.in.javascript.
Of course, you can try to mimic them - I've read half of a book teaching how to do that. But I've come to the conclusion that the complexity that you're adding to get you closer to your comfort zone ends up not being comfortable at all...
You have objects in Javascript. Some might argue that they're not "real objects", but wtf, they are what they are and bitching around all the time won't turn them into real objects. They are objects. It's the definition of "real" that is subjective :o)

The problems with JS:

- Silent errors. They happen. Get ready for them.
- Hard coupling everywhere. It's pretty hard to do loosely coupled architectures. It's quite easy to end up with a web of dependencies between different objects. I've read there are techniques to avoid hard-coupling, but I haven't had time to dig up more, so this might be my fault.
- Ugliness. I'm used to a HUGE-ULTRA-CLEAN separation between classes, libraries, modules, components and applications. In the webdev world, get ready to see PHP spitting HTML that has JS code spitting more HTML... Or function a() that creates another function in object b, that knows about object c and changes how c behaves. Things like that. In many known js libraries.
- It's not built for team work. At Webfuel we normally don't need to talk much with each other about development. Half a dozen guys can be working together for half a year on the same project, committing code every 5 minutes to the same SVN, without breaking the code of others. This was quite easy to achieve much thanks to the structured nature of Actionscript, on top of some very simple practices borrowed from the JAVA world. Enter Javascript and you'll see your code breaking the code of someone else. While developing JS in a team, it's normal that developers need to talk a lot about what each one is doing, warning the other to be careful about X or Y, or asking the other "where did you put the code for...". Actionscript makes teamwork a joy almost since moment zero - there's no rocket science for a healthy teamwork environment, especially if you're using a micro-framework. In Javascript, the trick is to put people working in very different unrelated parts of the projects and use techniques to encapsulate their code - I have yet to learn them, but I will soon. I've asked some JS developers about this but the ones I know are all lone-wolves so they didn't understand what I was talking about (apart from the reaction "SVN?? WTF?? Use GIT!".. hum... that wasn't my question...)
- Unpredictable. In AS3, the "this" refers to the instance where the method is defined. In JS, "this" can mean pretty much anything (remember AS2?). This was one of my biggest pain-points at first. Another problem is guessing by looking at the code the properties and functions of an Object. You can't. A function in an object can be defined pretty most anywhere. It's up to you (and your team; and your partners; and your library-providers) to make sure that you keep your house clean with everything organized in the right place.
- Code practices. These are completely different from everything you know. I taught everyone here at Webfuel to not be afraid of writing many lines of code. I want them to write self-explanatory code, like if they were writing English. Enter Javascript. And cry. By some weird reason, people like to write as much code as possible in a single line, making it not only very hard to read, but also very hard to maintain. I've got used to seeing the #('huge').line({of: code, that: function() { looks() }).like('a').train(); . And this practice is everywhere, pretty most in all examples, libraries and worse: in books! One of the books I read had one line that took me around 5 minutes to understand! The fun part is that I had the book with me in San Francisco on the Flex Summit and I showed that line of code to several people just to scare the shit out of them. It worked!

Bottom line: if you're an OOP purist, with many years of experience on software engineering on Flex and/or JAVA, you're going to be scared. The mindset is different. The problems are different. The solutions are different. Even the slang is different. The good part: no compiling times. Which is actually a very good part...

There's so many people betting in JS, shouldn't it be good?

This is actually the question that confuses me the most. I simply don't have an answer... Some people seem to be able to pretty much do anything they need but that doesn't mean their needs are the same as mine. At the same time the language certainly has its fundamental problems that can frighten anyone who has a one-year-project ahead.
One thing is certain: it's being pushed forward and you can't deny that.

CoffeeScript

I haven't tried yet CoffeeScript. After reading a bit about CoffeeScript, I've learnt that you still need to be comfortable with Javascript to use CoffeeScript properly. And that's what I'm doing. On the next project I might give CS (or other language that cross-compiles to JS) a try.

Layouting and the DOM

This was actually my biggest disappointment. Flex (>4) is amazingly simple and powerful concerning pixel perfect skinning and layouting. You have pretty much no constraints in Flex regarding layouting, giving you immense freedom in creating perfectionist user-experiences. You don't think "how am I going to implement this?" because there's not much to know about Spark skinning: it's really powerful and simple.
The HTML world is different. You have to be aware of the constraints before creating the design and setting the user experience. I wasn't aware of these constraints so we had to change the designs of the product we're building a couple of times on the middle of the project to turn them into something possible/easier to achieve in HTML. I really hate constraints that end up affecting the user experience, but that's how it is.

You have also to be prepared to accept small (and big) cross-browser rendering differences. They will happen. A lot. But that's another topic...

Optimizations/Preloading content

Coming from the Flash world I was used to have to build one single application (the SWF) that has all (static) assets embedded. This results in pretty small files (yes, a SWF is smaller than it's HTML+JS+CSS+Assets equivalent, even after minimization and gzip, and etc), only one request to the server (which ends up in a very low load on the server) and the assumption that all the content you need is available at runtime since moment 0. If you want to achieve a similar result in JS, you have to do it by hand - there's nothing taking care of that for you. You have to join and minify Javascript and CSS files and resort to image sprites to reduce the number of requests to the server and the user perceived speed.

An image sprite is simply one PNG file with all the images and icons you use in your webapp. Then you simply apply that image as the background image of your UI component, using CSS to set a translation so it shows the icon/image you need. It's quite simple, but make sure you load this image before your content appears on screen. The same applies to other content, in case you don't want the user to see "glitches" on the layout while things load.

During loading I am hiding most divs (display: none) in the DOM, showing a preloader and after all content is ready (JS files through Lab.JS, Image Sprite, etc), I'm using jQuery to show stuff. It's quite simple, actually, but of course, Flex did take care of all that for you... BTW, I saw this today, but I haven't tried it yet: https://github.com/thinkpixellab/PxLoader

I've started today looking for a Javascript minifier. I need something that can automatically watch a folder with several JS files and merge them in a single minified file. If possible, assigning a revision number to the generated file. I haven't yet found anything, but I'll update this post if I have positive results.

HTML(5), JS and Mobile

If you think you're going to build something in HTML(5)+JS that will work seamlessly and without problems in desktop AND mobile browsers, think again. Document based websites usually work without problems on both types of environments. But if you're doing a more or less advanced user experience that relies in some CSS and JS magic, then be prepared to be disappointed when you open your content in your Mobile device. Not that the mobile browsers are bad - they're actually pretty good. The problem is that the Mobile experience needs to be thought from the start - people will be using their huge clumsy fingers to interact, the screen will be smaller and the hardware resources are more limited. So at the end, you have to implement at least two different user experiences and switch between them according to the device capabilities using Media Queries. I haven't yet tried Media Queries, so there's not much I can say about this. I just mentioned this topic because I've seen several people getting frustrated after migrating their Flash applications to HTML expecting them to work right away on iOS. When in most cases it's probably cheaper to keep the Flash version on the desktop and build a dedicated version for iOS.

UI Components

DateChooser, NumericStepper, TextInput, DropDownList, RadioButton, Panels, Accordions, HGroup, Charts, Lists with Renderers, DataGrid, etc, etc, etc, almost all types of components you can imagine are available in Flex. And they are extendable and completely skinnable. You have great control in your hands. In the HTML world, either you go with the limited browser components - that are not extendable and are hard to skin but they integrate with the browser and the device -, or you have to choose a component library like jQuery UI, ExtJS or zkoss, among other - that are more or less powerful, but don't integrate with the browser or device.

After exploring dozens of options, all of them with their cons and cons, I felt unsecure on choosing one option, spending time and money learning it and teaching it to my team, to later conclude that I might have chosen the wrong one. So I've decided NOT to try any component library - apart from the limited jQuery UI -, simply because there are too many things changing right now and it's very hard to predict which libraries will succeed and which ones will not. I'm going to be lazy (also because I can't study thousands of stuff at the same time) and wait to see what other Flex developers will choose. In the meantime, as I said above I won't be using HTML(5) to build RIAs, but only simple webapps. And for that, jQuery UI is up to the task (with some quirks here and there).

Crossbrowser issues

Heck, this is my biggest nightmare. I tremble everytime someone says the word "web browser". Ok, I'm exaggerating a bit. Crossbrowser issues exist, they are a PITA and they will consume at least 30% of your time in a project (consider that when budgeting). But to be honest, at first I was expecting it would be a lot worse. Don't take me wrong here, crossbrowser issues are a nightmare. Simply, they're not as scary as I thought. If you follow me on twitter (https://twitter.com/#!/joaosaleiro ) you've probably seen me cursing some web-browsers (hint: has two letters, starts with an I, ends with an E). Get ready to having to test something in several browsers and to change plans in the middle of the project because your approach doesn't work as expected in one or two major browsers - especially if you're building edge-cases and using HTML5 stuff.

You can't miss this article: http://www.joelonsoftware.com/items/2008/03/17.html

We had one crossbrowser issue this week that almost killed our current project. We needed to override the browser URL while the user was navigating the application and we couldn't rely in simple URL hashes. We were hoping that history.pushState was up the task, but it happens that it is not. Erratic behavior in Safari, doesn't work in IE, worked in Android until 2.3.3 and stopped working in 3.0 and 4.0 (WTF?)... Fortunately, we've found History.js which was built exactly to fix our problem and reduce (not fix) the cross-browser issues. See, the good thing is that crossbrowser issues happen to everyone, so there's a high chance you'll find a workaround on the web.

If you're doing HTML5 you probably know about http://caniuse.com/ . If you don't, go there.

Productivity

Our productivity is pretty bad right now (but we are getting better!). We've spent 11 weeks of two resources to build something in HTML(5)+JS that we would have built in 3 weeks with the same resources in Flex, without any stress at all. Of course, I take a big part of the guilt here: we're still learning and during the first weeks there were a lot of readings, plan changes, tests and bumps on the road.
The real issue is how tight the relation between productivity and your experience with the tech is: the bumps on the road are there, they happen to everyone and you won't be able to predict them. So the only solution to be productive is to be experienced and be aware of those issues. They will simply happen, you'll curse them, search the internet for hours, fix/hack them and the next time you'll meet them, THEN, you'll be prepared and productive.
You'll end up implementing workarounds and hacks (on top of other hacks) constantly. Coming from the Flex world, you'll feel ashamed of your hack - don't be. It's normal. Most of the times, you won't have another choice but to accept the hack and move on.
Coming from a rapid development environment as Flex, productivity in JS and HTML can be quite frustrating until you get used to the bumps on the road. After you're experienced, it will get better, but I don't expect it to come any close to the productivity of Flex development in a near future.

Conclusions

The first conclusion is that we'll keep using Flex in long-term enterprise RIAs projects, especially targeting installable desktop and mobile applications. Neither the open-standards nor us are ready to build the same type of experiences that our clients expect us to.

At the same time, we'll be accepting smaller webapps. At this point, after three months, we're already pretty comfortable building web experiences, so it's a matter of raising the bar slowly, webapp after webapp. But I don't think we'll be able to do the same type of RIAs we were doing with Flex at least not in the next two years. Also, maintainability and its cost scare the shit out of me. And all the moving parts of HTML5 - new libraries appearing, others disappearing, browsers adding or dropping support of features, etc. There are lots of "ands", "ifs" and "nots".

I know I've missed half a dozen important topics and I know I'll have dozens of other to write about in a couple of months. Actually, there are no real conclusions here - only open subjects. There's much to be investigated and learned. I'm sure I'm not completely right in some of the above topics and I would love to get your feedback, pointing me in the right directions where I got it wrong. I can only hope that most of the stuff I pointed above won't look as bad in a couple of months as it looks now. Or that browser vendors shake hands and decide to stop fragmenting the web. Maybe they could all be friends and adopt the same rendering engine and VM ( giggles ). For example, Google Dart. ( yeah, right ...)

About Author :

João Saleiro

Project Manager / Software Engineer / Partner @ Webfuel

Graduated in Computers and Telecommunications Engineering @ ISCTE, Portugal

Certified Instructor

Adobe Certified Expert in Flex, Adobe Community Professional, etc

Loves sports, cinema, researching and engineering.

8 things you should know before building a mobile app

2012-02-06T22:36:00.001+05:30

The upshot of producing the next Angry Birds or beer-chug simulator? So high!

Heck, with just a small investment of time and cash, it's not hard for would-be mobile moguls to turn a concept into a steady stream of cash. And thanks to today's app stores, it's never been easier to try your hand at becoming the next tech tycoon.

Here's (almost) everything you need to know before you get started on your own app -- and what I wish I knew before I got into the game.

1. What does it cost to make an app?

If you're new to the app game, prepare for some sticker shock. Making an app will cost you, at the very minimum, around $10,000. This is for a super-simple program — none of that fancy enterprise or social networking jibber-jabber. Even still, any app worth its weight in code will likely cost you closer to $20,000.

Unless you have some basic design skills, you'll need to enlist the help of both a programmer and a designer. And these guys ain't cheap — particularly programmers who, thanks to a pronounced shortage of qualified coders, can pretty much name their prices. (A suggestion for those low on funds: Find some creative way to come up with the cash. I funded my app through Airbnb income.)

You can try to offload some of your costs by offering your guys equity; on the other hand, everybody tries to get free (or close to free) apps by offering developers equity. So unless you can really sell them on the strength of your idea (or bring something totally rad to the table, such as a celebrity), you better be prepared to pony up some cash. Of course, adding in some equity as a bonus is never a bad idea, so you'll probably want to dish out some shares too.

This basic supply/demand dynamic also means that many developers ask for some pretty insane terms. Some demand deals that involve a huge upfront payment in exchange for a few weeks (or even just days) of work. And if a decent developer isn't already working full time, it's not unreasonable to assume he's at least a little commitment-averse. So, if you're serious about making something beyond a quickie cash grab, find a developer you are sure will stay with the project for updates, and not abandon it the second it hits the store.

And get it all in writing. If you don't want to hire a lawyer, find a boilerplate contract online or get one from somebody else who's gone through the process, and just swap in your names and numbers.

If you can, you'll also want to work with people who are local to you -- or at least with people who are willing to join you for regular Skype chats or Google Hangouts. I had weekly beer summits with my coder and designer, which proved super helpful as we continued to fine-tune our app well into its development.

One more unavoidable cost: Apple charges $100 per year to hold onto a developer's account (which you need to publish your app). So be sure to reserve an extra Benjamin for your budget.

2. What should you charge for your app?

I would consider starting one's app at or near $1.99. It's premium price, but it's also immensely satisfying to get more than a buck per download after Apple takes away its 30%. And, as with most things, it's a lot easier to lower the price later than it is to raise it.

During the holiday period, we briefly played around with a special promotion that dropped our app price to $0.99. Predictably, this spiked our downloads, but it didn't actually raise our total revenue. Even on Christmas Day -- the single biggest download day for just about everybody — our revenue was actually higher a week or so later, once we had raised the price back to $1.99.

The obvious exception: If your primary business model involves in-app purchases, ads or the like, you'll probably want to give your app away for free. After all, a quick glance at Apple's top grossing charts shows a whole bunch of free apps.

3. When will you get paid?

Apple sends you cash one month at a time, up to 45 days after the month has ended. So, if your app goes live in January, you can expect your first kickback sometime in early March. Oh, and Apple only pays you if your earned amount totals at least $150, so you may have to wait before getting your first payment. Keep in mind, Apple only pays you through direct deposit.

4. How do you write your iTunes description?

Don't try to rock the boat here. Take a look at a bunch of hit apps, and crib their formats. If it works for them, it'll work for you. Typically, this involves a quickie intro statement, press blurbs and a list of your key features. Then add some screenshots (the most interesting ones first) and call it a day.

5. What's the best way to beta test?

Getting an unreleased app onto your friends' iPhones isn't the easiest thing in the world. My developer and I are in total agreement that the best method is a program called TestFlight, which makes it very easy to send build updates to registered devices, over the air.

6. What happens when you get featured on iTunes?

Getting featured on iTunes is obviously awesome, but what exactly does it get you? When Apple included our app on its featured lists, we enjoyed a predictable flow of downloads almost identical in volume every single day we were parked there. Especially fascinating, the "New & Notable" list gave us almost exactly twice as many daily downloads as the "What's Hot" list. I'm assuming this is because, when you tap the "Featured" tab on the "App Store" app, "New & Notable" pops up by default.

7. How do you get press?

As a longtime tech writer, the main advice I can give you in your pursuit for press is that less is more. If you think a site or publication would be into your app, don't e-mail the entire staff or the big boss — just find the writer who covers your category, briefly summarize your app in an email, and attach a download code (Apple gives you 50 for every update). Smaller sites may be more responsive than the big guys, and if you build up enough buzz, you can rest assured that the majors will come knocking.

If a journalist doesn't get back to you, move on. And don't even touch that phone or personal e-mail address (unless that person is a freelancer) -- writers hate nothing more than phone or personal-inbox press pitches.

Consider also producing an embeddable YouTube or Vimeo ad of some sort. Not only does this provide one more avenue for people to stumble upon your app, but it also gives bloggers something alive and colorful to toss into posts, which could increase the chances that they'll write about you. Keep it simple, and preferably, well under two minutes. And don't forget to promote over Twitter, Facebook, etc.

8. How do you avoid the spam?

Within days of hitting the App Store, expect whichever email you linked to your iTunes developer's account to be pounded with spam. Most try to lure you into ponying over money in exchange for positive reviews, under the guise of "mobile marketing." Let's put it this way: If you don't regularly buy Viagra pills online, then you probably shouldn't give cash to these guys. Of course, if you're smart enough to make an app, you're smart enough to know this already.

6 levels of web app interactivity

2012-02-06T19:36:00.000+05:30

Level 0: Static A pure, read-only, static HTML experience. e.g.:http://isthewebdead.com

Level 1: CGI Any dynamic behaviour requires clicking on a link or submitting a form, then waiting for the server to produce a new page. e.g. http://hackerne.ws

Level 2: DHTML Lightweight JavaScript enhancement which doesn't impact on core functionality, such as client-side validation, visual effects, or analytics tags. e.g. http://wikipedia.org.

Level 3: Hijax The progressive-enhancement approach where the server outputs full web pages, but they are enhanced ("hijacked") by client-side JavaScript to produce functionality not available to static clients. e.g. http://flickr.com

Level 4: Single Page App All UI logic and usually large chunks of business logic in the client. The server provides a purely RESTful exposure with no UI logic or state. e.g. http://webwait.com

Level 5: Live App A single-page app reflecting live server state using Comet (specifically, XHR hacks, WebSockets, Server-Sent Events, or Flash/Java equivalents). e.g. http://trello.com

40 Eye-Catching Dark Website Layouts

2012-02-06T00:37:00.000+05:30

Web designers are constantly looking for hot new trends to catch their visitor’s attention. This list of exciting design trends has changed dramatically in the past 10 years, but dark-themed websites have always been in style. This color swatch combined with many different web elements is a surefire way to draw in attention. If you’re a fan of these deep-rich color schemes please spend some time perusing my design gallery.

Kisko Labs

Crafton

ImGame for iOS

Casa Vaello

FFFFALLBACK

Capo for OSX

Abduzeedo

GR Packaging

Riff Raff Web Design

Abstraktion

ci design

wopro

Cockpit for Mac OS X

Versions App

Espionage

Cornerstone

Plex

Jet Cooper

Designers MX

LA Bubbly

This man’s life

DonQ Rum

Rogge & Pott

Alien Bikes

James Garner portfolio

Pokkisam

Pirata Digital

MadeToKill

Youzee

Kineda

Cobra Creative

Skewed Icons

Justdot

vyniknite.sk

Lubuski Hip Hop

Newcastle Web Design

42 Angels

Kettle NYC

Carbon Ads

Visualbox

My First Year Fighting Spam by Clément Genzmer

2012-02-06T00:06:00.001+05:30

Fighting spam is really an arms race. As technology evolves, new threats emerge and keeping up is an absolute necessity. The Site Integrity team at Facebook works to protect people from spam, scams, account compromises, and other forms of abuse by building real-time classification systems that process millions of interactions per second and investigate and respond to new threats.

At the beginning of 2011, I joined a new sub-team on the very front line of the war against spam—Recon & Response (SI-RAR). This team is constantly fighting against the biggest and most pressing threats out there, and when things are quiet, we build more defenses. Here's a look at some of the attacks we worked on last year and the new systems we built to combat emerging threats.

Fake accounts
When I first joined SI-RAR, I immediately started battling a fake account attack. Typically, spammers pose as attractive women to have their friend requests accepted and then use this friendship to send spam. Spammers will go to great lengths to create accounts that look as real as possible, generating fake backgrounds, fake photos, and even fake conversations. In this particular case, a website for Russian brides created fake accounts to promote its services. We had already done a considerable amount of work to identify and shut down these accounts before a single friend request could be sent, but this case was different because these accounts would not send friend requests, but rather comment on some public threads in hopes of receiving a friend request. I learned very quickly that it is very common for attackers to react promptly to the protection we put in place—sometimes within hours. So, I cut my SI-RAR teeth by tweaking our systems often and disabling all of these fake accounts.

Social engineering attacks
In May, we faced a new form of an attack now known as "self-XSS." Security engineers have known for a while that social engineering attacks (where you trick or deceive people) have the potential to be bigger and more dangerous than attacks leveraging an actual security hole. Normally, one of these attackers will use a fraudulent hook to lure people (shocking Justin Bieber video, free iPad 3s, gift cards, free airline tickets, etc.) and then ask them to copy and paste code to access these special items. However, this code is a piece of malicious JavaScript that allows the spammer to post on person's profile and their friends' profiles.

Contrary to a typical cross-site scripting (XSS) vulnerability, which is a security vulnerability in Facebook's code that would have to be fixed, with self-XSS there is nothing to "fix". We've talked to browser teams across the web and they have made progress, but so have the spammers. Right now, the attacker directly asks people to open the JavaScript console, thereby circumventing some of the newer browser protections. Whenever we detect that someone has been tricked, we put them in a special flow to explain what happened to their browser during this attack and at what point their account was compromised. One important lesson I learned here is that you really cannot take for granted that everyone knows what Javascript is. And as a result, security cannot be an afterthought, it has to be carefully designed within the product.

Monitoring
As you can imagine, attacks do not spike on Wednesdays at 2:00 p.m. when everyone is at their desks, ready for the smallest incident—that would be too simple. They usually start on Friday night, and by the time you open your computer on Saturday, the attack is well under way. Spammers are located all over the world, especially in countries where it is hard to prosecute them. They have day jobs, very often in computer security, and they are always planning strikes around times we are less likely to be at work. Data and automation are our best friends in this world and we use these tools to constantly monitor all negative interactions happening on the site (friend requests being declined, messages reported as spam, etc.). On top of that, an important part of my job is to research and predict what is going to come next and plan for the attacks that we don't know about yet.

Malicious extension
Last month, we noticed a significant change from self-XSS to malicious browser extension. The upside is that we blocked self-XSS well enough that the attackers had to find a new vector for spam and changed to something with a lot more friction. This browser extension is essentially a virus that people install on their computer under the illusion they are installing a video plugin. We have been working with the browser vendors to fight these extensions and are deploying more advanced counter measures all the time.

And so this was 2011. We saw old attacks declining (drive-by download) and new attacks showing up (self-XSS), and we've put new protections in place that we will continue to iterate on this year. However, a team of security engineers will never be as effective as millions of users aware of security issues. To learn more about how to better leverage our tools to secure your account, check out ways to take action here <https:>.</https:>

My team works hard to build spam protection that will secure everyone's account, and with more than 800 million people using Facebook, this is a considerable challenge. But everyone on my team is always on-call, ready to fight. I joined Site Integrity because I liked ML problems and thought I could have a big impact working on security, and two years later, every day still brings a new set of challenges.

About the Author :

Clément Genzmer

École Polytechnique · Facebook

Here is a post he wrote a post for the facebook engineering blog. It is a sneak peek in the world of spam fighting

- Thanks to Frederic Wolens, Pedram Keyani and Alex Hollander for their feedback and edits!

Developing basic Metro style apps (JavaScript)

2012-02-01T22:57:00.001+05:30

This section walks you through the steps to create a complete but basic Metro style app using JavaScript. Metro style apps are focused, fluid, and elegant. From the new Start screen to new UI layout and controls, the presentation of your app is about showing off what it's great at.

Creating a UI
Learn how to create a user interface for your app.
Responding to user input
Learn how to respond to touch, keyboard, mouse, and ink.
Accessing files and data
Learn how to read, write, and save to files, as well as how to manipulate XML data.
Using async programming patterns
Learn how to keep your app responsive with asynchronous programming.
Managing the application lifecycle
Learn how to launch, suspend, and resume your app while keeping app data safe and fresh.
Defining application resources
Learn how to define your app's resources to improve maintainability and localization.
Packaging your app
Learn how to use Visual Studio to create an app manifest and package your app.
Debugging and testing apps
Learn how to use tools to debug and test your app.