REST API simplified

Before I get philosophical, here is the gist:

For the function:

• getPhoto(String photoName, int userId, int width) 

In the controller:

• PhotoController.java 

The suggested rest API is:

• http://hostname.com/api/photo/get?photo_name=flower&user_id=123&width=1024

Or in more general terms:

• {protocol}://{domain}/api/{controller_or_service_name}/{short_function_name}?param1=value1&param2=value2&paramN=valueN

Philosophy

I've worked with dozens of rest API's and also created a few. Some conventions are very simple and easy,  some are complex.

When creating an API you have three players to think about:

1. The developer (probably you)
2. The client developer
3. The end user

The developer (you)

You are your own client, and so are the developers that will inherit and maintain your code. Creating a self-explanatory API means making it easily expandable.
If you are developing a service layer or a controller layer, I suggest adding their name to the path, right after the host:

• host.com/photo/

This will make it easy to to find the right controller when maintaining the code. This will also, usually be, either the object that the function returns, the main object that it manipulates, or the name of the main action, in that order of priority.
For the same reason, immediately after, put the short name of the function that handles the parameters:

• host.com/photo/get 

Then come the query parameters themselves:

• host.com/api/photo/get?photo_name=flower&user_id=123&width=1024

Non abiding order, optional and nullable.

The client developer

If you only had the client on your mind, using query parameters for everything would be the best choice, their order is non-abiding and they are all optional. But this will require creation of a special function for navigating to the right controller and make it imparseable to the user.

The end user

If you were only to think about the end user, you would probably use very few query parameters (e.g. id=123) and mostly path sections (e.g. photo/id/123). Path sections are cleaner looking and use one simple delimiter character ("/"), so users have an easier time navigating your API. But this is where user simplicity ends, and developers' complexity begins:

1. Using a path for dynamic data like a user's id could cause some trouble:
• if the function can handle a null value
• if it includes special characters.
2. The order of the parameters is static and the client developer can't just throw them on using a query parameter map.
3. Arrays and JSON objects can't fit in a path.

To sum it up:

• http://hostname.com/api/photo/get?photo_name=flower&user_id=123&width=1024

Or in more general terms:

• {protocol}://{domain}/api/{controller_or_service_name}/{short_function_name}?param1=value1&param2=value2&paramN=valueN

And here are a couple additional examples:

• Function: deAssociateUserAndPhoto(String userId, String photoId)
  API: http://hostname.com/api/user/deassociate ?photo=456 user=123
• Function: MapService.getDistance(Point a, Point b)
  API: http://hostname.com/api/map/distance?point_a=42.365,31.987&point_b=36.743,28.234

The real difference between static and dynamic programming languages

The real difference between static and dynamic programming languages from an entrepreneur's point of view.

The debates are endless and tiring, you can get a taste at stackoverflow.

But when push comes to shove, and you really want to know what is the actual real-life difference between statically typed (aka Java) and dynamically typed (aka python) programming languages...

It all comes down to this simple explanation:

• Dynamically typed = Easy Get up
• Statically typed = Easy Maintenance

When using dynamically typed languages, you are much faster in constructing a new project, and you need less lines of code than a statically typed language to do most things. Later on, when you'd want to poke around and change stuff, it would probably be harder.

When using statically typed languages, it's easier to maintain, change and refactor the code, but you have to do more work to get things going.

For example, defining and sorting a list:

Java (static):

List<integer> a = new ArrayList<integer>();
a.add(5);
a.add(2);
a.add(3);
a.add(1);
a.add(4);
Collections.sort(a);

python (dynamic):

sorted([5, 2, 3, 1, 4])

As you can see, Java (static) is longer to type and you have to know about many keywords, pyhton (dynamic) is much shorter and self explanatory...
But if one day, you would want to change some of the objects in the list, and accidentally put a "text" object instead of a "number":
python would just handle it and treat all of the objects in the list as text objects. You would only find out about your mistake when the program runs and a human actually looks at the output and realizes something is misplaced.
Where in Java, the program will not even run, so you would know immediately where and what to fix.

You can say that python is "smarter" because it adapts to the data, and you would have a point... but when you have thousands of lines of code, and many programmers, you want zero flexibility and you want to be notified of any inconsistency.

So to sum it up:
If you want speed at the beginning, use a dynamic language.
If you want easier long-term maintenance, use a static language.

What do you think? comments/corrections are welcome...

The Art and Science of Fundraising (Excerpt)

The Art and Science of Fundraising - excerpt

According to Scott Weiss from Allegis Capital.

1. I hear and I forget, I see and I remember, I do and I understand.
2. Get multiple term-sheets (offers).
3. Leave a positive impression on everyone you meet.
4. Valuation by perfection, be pedantic on every investor touchpoint.
1. Team
1. CEO
1. Authenticity - don't be phony, sweat, show your weakness, be yourself, know what you don't know, don't be defensive.
2. Coachability - solicit feedback, surround yourself with mentors, you are a share holder before ceo.
2. Chemistry, don't interrupt each other, everyone talks about what they know best.
3. Match up your team to the investor team: Tech specialist -> geek, Numbers guy -> marketing, 2 to 1, 3 to 2.
2. Market opportunity
1. Tell a story in your slides, keep it short,
2. You know all the questions, 20-30, prepare for each one of them. Know which team member is going to answer them. The ceo is like a point guard, dish out to the member who knows the answer.
3. Competitive advantage
4. Traction
5. Practice, practice, practice, start with tier 3 investors and move up.
6. Cast a wide net, meet many VC's and angels in a short time. Makes the deal hot.
7. Talk with other CEO's before choosing a term sheet.
8. Have a user advisory board, if an investor ever needs to call a user. give them stock. get their cellphone.
9. Know the time to close, due-diligence period.
10. Small odd-number board, majority of founders and independents (non-vc's), could be experts.

The Art and Science of Fundraising from Allegis Capital on Vimeo.

Setting up google analytics EasyTracker for Android

• Add libGoogleAnalytics.jar to your project's /libs directory.
• Add EasyTracker.jar to your project's /libs directory.
• Add the following permissions to your project's AndroidManifest.xml file:
• Get UA code from your analytics admin section
• Add your UA code to your values/strings.xml like so: UA-xxxxxxxx-x .
• Change the activities you want to track-
• from: Activity / ListActivity
• to: TrackedActivity / TrackedListActivity

you're done!

Skynet attacks stock market

I never thought Skynet will attack the stock market first...

Watch this terrifying GIF and see how robots have taken over the Stock markets.

Wait until 2012...

iOS 6 predictions

Here are the features I predict Apple will reveal on 11.6.12 for iOS 6. What do you think?

• Swipe from bottom and from the sides: the same algorithm that opens the notification center when you swipe the screen from above, will also be implemented to all other sides. When you swipe from bottom: the multi-task fast app switcher will show (no more agonizing double taps!), swiping from sides will switch back and forward between previous applications exactly like the 4-finger gesture on the iPad does.
• Siri API: developers will have an API to add question "templates" to Siri's vocabulary, for example: saying "Play %q from stitcher" will identify the word pronounced instead of "%q" and will send it to the Stitcher app. So, saying "Play the verge from stitcher" will launch the stitcher app and play "the verge" podcast.
• iMessage API: Since iMessages are free, Apple will open an API that will enable developers to send them programmatically, opening the flood gates for specialized messaging apps like delayed texting, location based texting and more.
• New notification interactions: till this very day, there are only two ways to interact with a notification coming from an app: dismiss it or open the app. As a developer you would like to give your users the power to delete an object in a notification, snooze it or open an automatic reply. The new API will let the developer add a button to the notification, or maybe even a select box. In fact, I think apple will add a "snooze by time" option to iOS's native calendar notifications.
• Social info: this app would like to know your gender and your age. Apple will continue adding social hooks like "find my friends" and "ping".
• Photo sharing: you'll be able to photo-tag friends from your contact list, and this will send them a link and pop the photo in their photos gallery.
• 3D iMaps: no doubt.
• AppStore on the Apple TV: no way, only when the iTV will be announced, which is not at this WWDC.

Left overs from iOS 5 predictions

I still really want these:

• Widgets: app icons will now have various possible sizes, constrained to combinations of multiple icons. For example, to make a search widget, you can define your icon by 3x1, meaning 3 icons across and one vertical icon. The widget will occupy the space of 3 icons horizontally on the home screen and will behave exactly like an application with transparent background.
• Xcode for the iPad: This is more of a wet dream, but Apple is building on the iOS as their main operating system for the future, and to get the real hardcore users to move to it, they have to make an IDE available. The main reason I gave up on my iPad and gave it to my mom was the lack of a good IDE (plus she really liked it :-).

A laptop with a wired and detachable touch screen

A laptop with a wired and detachable touch screen.

How often do you see a person using an unplugged laptop?
A rare sight indeed.

I know some people who've never actually used their laptop batteries, they removed them the minute they bought the device to keep their batteries healthy once they actually need them.

Most of the time, we are using our computers when we are sitting.
So why not create a powerful laptop with a detachable touch screen?

When you need to do a keyboard-intensive task, use it as a conventional laptop. When you want to lay back and do some casual browsing, angry birding or reading, detach the screen and do some finger computing. All while having access to the fully featured and powerful CPU, memory and operating system.

The screen is just that, a screen, hence it can be extremely light and comfortable to hold, the wire won't really get in your way.

You can think about it like an iPad with an i7 intel CPU, 16gb of RAM and a 256gb SSD, minus the weight of the ipad batteries, and all the internals.

I guess a 1.3 kg computer can be transformed into a killer 12 inch wired touch screen computer that weighs just 300 grams, less than half the iPad, and as little as two iPhones.

The weight is more noticeable in your hands and on your lap, rather than on your back or in your briefcase. So just unload the weight away from you, put it on the floor, or on your desk, exactly like you do with the cord and the power brick of most portable computers out there.

Wait a sec! You can hide all the internals in a large power brick and that way, it will look like magic, desktop horse power channeled through a wire from the floor, to a light touch screen in your hands.

A data center on the sun

As data intensive and super computational tasks demand are rising at an exponential rate. Costs of energy in data centers are becoming the most expensive factor in our world-wide data driven network, aka the Internet.

Ideas of harnessing energy from the sun and sending it back to earth has been around for awhile, but sending energy remotely over microwave is extremely dangerous and and, well, experimental.

Sending data remotely, however, is much more safe and easy, we've been doing it with satellites for dozens of years.
Data center satellites, imagine sending hundreds or even thousands of small solar computers to surround the sun, feed off the energy of our sun and compute our every wish. Earth bound control centers will send out the formulas to compute and will catch the messages of the results when they are finished.

A server node swarm surrounding the sun and turning light and heat into computing power.

Location:קהילת פאדובה,Tel Aviv,Israel

why JAVA is the most strategic programming language to learn

This is why JAVA is the most strategic programming language to learn:

If you master JAVA, you can develop any type of software:

• most devices: Android
• most consumer servers: AWS and GAE - web apps
• most business servers: JavaEE - Big corporations

Overcome i18n empty string error message

The problem:
If you are using an i18n supported system like spring (java), there might be a scenario where your application might call an empty string.
This might occur when you invoke the i18n with a null or an empty string (i.e. the i18n key was not set correctly and the jsp i18n tag could not find it).
Then, when trying to translate the message using your i18n messages.properties file, the server might throw an exception.

That exception might be disruptive in a production environment.
In order to throw a silent exception, I took the approach of null vs. empty object handling.
(i.e. prefer returning an empty object rater than null, when an error occurs).

The solution:
To avoid this exception, you can add an entry for an empty string to your i18n messages.properties like so:

conf.btn.submit = SUBMIT
conf.status.none = NONE
conf.status.deleted = DELETED
conf.status.inactive = INACTIVE
= i18n empty string error
conf.status.active = ACTIVE
conf.status.incomplete = INCOMPLETE
conf.status.pending = PENDING
conf.status.approved = APPROVED
conf.status.rejected = REJECTED

Ofcourse, you might want to use some other text than "error" according to the specific need of your application. Displaying "Error" is a way of floating up the problem without displaying the user/QA a blank screen.

Note:
This technique could also be used in development to focus on business logic development, however, I would recommend DELETING this empty i18n key during the last test days, before going to production, to minimize such exceptions.

Configuring envers with maven

Configuring envers with maven, hibernate and spring on eclipse.

1. In eclipse
2. find pom.xml
3. click on the pom.xml tab to see the actual xml code
4. Add the JBoss Repository according to: https://community.jboss.org/wiki/MavenGettingStarted-Developers
5. Go to the Dependencies tab on the pom.xml
6. click Add...
7. Start writing "envers" in "Enter groupId..." field
8. "org.hibernate hibernate-envers" should appear in the results, instead of the latest version, enter your hibernate version, or "${org.hibernate.version}" to copy it dynamically.
9. save pom.xml

You now have envers configured, just add @Audited above the classes/properties you want to audit.

Version Control strategies for new software

Here are three VC strategies for new projects, they are not fit for legacy or maintained production systems.

Live trunk

Suited for new projects with small teams.

/trunk - Latest code, constantly being committed to. May not work, code is sanity checked and compilable.

/branches/versions - Stable and tested, weekly/monthly snapshots of the trunk. For reviews and QA, Never changes. Can also be just labels.

/branches/cross_features - Potentially dangerous, experimental and cross-conflicting, cross-team features. Merged to trunk when the feature is done. Should be used rarely.

Team branches

Suited for projects with very isolated teams (especially offshore).

/trunk - Stable, fully tested code, never committed to, only merged to.

/branches/teams - A branch for each team, merged weekly or monthly to the trunk with extensive testing.

/branches/versions - Same as "Live trunk". Stable and tested, weekly/monthly snapshots of the trunk. For reviews and QA, Never changes. Can also be just labels.

Feature branches

Suited for more mature projects with more code lines and at least 3 people working on each feature.

/trunk - Same as "Team branches". Stable, fully tested code, never committed to, only merged to.

/branches/features - branched and merged from trunk after features are fully completed and tested with trunk.

/branches/versions - Same as "Live trunk". Stable and tested, weekly/monthly snapshots of the trunk. For reviews and QA, Never changes. Can also be just labels.

iBooks 2 is actually a web-app store

Think about it, Apple never planned the native application Store we have today. They were forced into it by the genius hackers who made amazing apps for the first jailbroken iPhone.

When introducing the first iPhone, Steve said web applications are everything you needed to enable rich application functionality.

Hello iBooks 2

Besides the chrome web store, there aren't any popular web app selling platforms out there. And definitely not mobile.

iBooks author is actually a visual IDE

You can create and sell rich pages that include applicable functionality using JavaScript. The gazillion of content web sites out there can now start charging for their text, images, video and JavaScript code for widgets.

Bigger than the App store

The app store is very big, but not as big as it could be, because iOS apps are written in Objective C which is not as easy or popular as other languages. iBooks "BookApps" (that's how they should be called) are written in in drag & drop, and the complicated stuff is in JavaScript, one of the most widespread languages in the world, thanks to the world wide web. In short, writing BookApps is much easier than writing native apps. BooksApps won't have most of the interesting API's like accelerometer, storage access and camera, but they might come one day. And till then, most content apps and simple functionality one could be written faster and easier for the iBooks platform.

The chargeable web

I'm not sure if this is Apple's goal, but they are actually creating a chargeable version of the web, from the second iBooks author was out, most content websites can easily create a chargeable version of their content.