Tag Archives: java

Never use hard tabs

Posted on by
89

Update: This post has been updated to address some of the claims in the comments. Please note that most of these claims are wrong 🙂

As there seems to be some confusion when hard tab characters (ASCII code 9) are appropriate in source code files here is a rule:

1) Never use hard tabs

1. 1) Unless your source code is hard tab sensitive (only such format I know is Makefile)

1. Reasons not to use hard tabs

  • Due to legacy, different text editors treat hard tabs different. UNIX text editors prefer hard tab is 8 spaces, Windows text editors and IDEs (Eclipse) prefer that a hard tab is 4 spaces.
  • The hard tab length agreement between different text editors cannot be reached
  • The hard tab length agreement between people cannot be reached
  • Thus, hard tabs may break source code readability and editability if there is more than a single person editing the file. They will open the file in an editor with different tab settings, edit it and next time you open the file it is ruined and all indentations are wrong.
  • This is even worse on white space sensitive languages (Python, CoffeeScript) as this might actually cause syntax errors or programming logic errors

However, you can avoid this problem in the first place if you do indentation using soft tabs (spaces) instead.

Even if you were the single person in the world editing the text file, even you might switch the text editor in some point and accidentally shoot yourself in the leg.

2. Using soft tabs for indentation and having no hard tabs should not be a problem because

  • All text editors can convert tabs to spaces in fly, when editing the file. Please note me if there are commonly used editors, besides Windows Notepad, which doesn’t do it yet.
  • Text editors usually have different settings to tab key length and indentation settings. The latter is what you really want to adjust.

3. Pseudo-arguments for using hard tabs

  • It makes the file size smaller: you really care about those twenty bytes on your gigabyte hard disks?
  • This one I made up: spaces count toward the file size in web stuff, because visitors download the files. However if those bytes really matter you that much you should be using a minimizer in the first place.
  • I like them arguments…: rationale not involved
  • The change resistance in human nature

You might have a legacy software project having its legacy style guides. If the project big, e.g. Linux kernel, the switching cost may be very high and not affordable. However, even with this kind of codebase, you can gradually replace hard tabs away.

4. Style guides (updated)

Hard tabs are required only in Makefile syntax and preferred only in Go style guides. This is because people have learn by experience that hard tabs cause mess when working with other people.

5. Tab character is not semantically the same as indent level (updated)

There is no style guide or coding conventions saying that the tab character should the indent. This assumption is easy to make because it allows you to stick your head into a sand, ignore the surrounding world and by singing “let the users pick their own tab width” mantra. However, though a cunning idea, this perceived simplicity causes compatibility and co-operation issues which this post tries to highlight.

6. The user should choose to their own tab width (updated)

To choose your own preference is the rationale many people claim is the reason for indentation by tabs. “Let the users pick their own preference for indentation” However if you indent to work with other people the recommendation is to stick to the programming language recommendation. This way people can be more easily pick up the codebase.

There is nothing gained by having “user chooseable indentation width by adjusting tab character width”. The most used indentation width is 4 spaces anyway, so it is extra effort to maintain the freedom to have a user pickable indent width number instead.

Try to go to tell some old UNIX admin that they must adjust their editor tab width (see below).

7. Tab width is 8 spaces and don’t mess with it (updated)

People who use tabs as indent assume tab one tab = one indent and they can freely adjust the tab width, so that the indentation looks nice. However

  • By legacy, the tab character width is 8 spaces and most of the software out there makes this assumption. If you use any other value for tab width you are breaking this legacy social contract and you are making it for other peoples more difficult to work with your project.

This really limits the ability of using tabs as indent, because 8 spaces tabs often don’t make sense as indent (exception in system style C programming like with Linux kernel).

It’s ok if you work with the code in only one text editor alone where you have this one setting for tab width and that’s the only setting in the world controlling the tab width in your source code project. But when someone else must read or edit the code

  • Others must adjust tab width to make your code more readable
  • Adjusting tab widths from 8 spaces might be very difficult when working with other toolchains (e.g. you are viewing the code in terminal using cat)

Also in the languages where the recommended indentation level is only two spaces it would make it little funny to use one tab character just to have two spaces.

8. Tabs cannot be used to format code multi-line functions (updated)

Some people prefer to format long argument lists like this. A Python example which would break because of mixed tabs and spaces if tabs are used as indentation

call_a_function(argument,
                very_long_argument="something",
                even_longer_argument="something_else)

 Or in C

   if (first condition
       second condition)

9. Text editors

If you are a text editor author, make sure your text editor ships with hard tabs turned off by default, especially for whitespace sensitive languages if you vary tab policy by file type.

Note that this blog post, and the situation, could have been avoided if

  • All text editors would have sticked to soft tabs by default
  • All text editors would have sticked to a hard tab is 8 spaces by default

But in some point (when?) someone (who?) decided to make our life little more complex.

10. Tools for managing hard tab policy in your software project

\"\" Subscribe to RSS feed Image Follow me on Twitter Image Follow me on Facebook Image Follow me Google+

Testing mobile sites on Firefox Mobile, Opera Mini and other aftermarket browsers (Mobilizing websites with responsive design and HTML5 part 12)

Posted on by
2

This blog post is a part of Mobilizing websites with responsive design and HTML5 tutorial. For all posts please see the Introduction post.

Firefox Mobile and Opera Mini are popular after market browsers the user can install on their device. They offer additional functionality and speed over the stock browsers. You should also test your mobile sites with these browsers.

There also exist plethora of other after market browsers, especially for Android platform. I am not sure how popular they are, but they all are based on the same WebKit engine shipped with the Android platform, so they generally yield the same rendering output as the Android Browser stock browser does and separate testing is not needed.

1. Opera Mini

Opera Mini has over 100 millions users and it is the most popular mobile web browser.

Opera Mini is not a full web browser – it’s a thin client. The pages are rendered in a server-farm in a Norway where Opera comes from. The servers send a compact subset of the webpage page to the handset instead or raw HTML, CSS and Javascript. This allows even the most low powered devices render complex web pages.

The thin client strategy in web page rendering is also used by Kindle Fire.

2. Opera Mini simulator

Opera Mini Simulator is a Java applet which you can run in your web browser.

Image

3. Opera Mini on devices

You can install Opera Mini on any device, including low-end phones and iOS devices.

Sadly, Opera Mini offers little debugging tools because the pages are rendered on remote servers. Your best shot is use Opera Mobile to render the pages, as the underlying Presto rendering engine is the same.

Opera Mini, even if being thin client, can execute Javascript on page load and click handlers on the server side, but the execution time is limited (around one second).

4. Opera Mobile (not mini)

Opera Mobile (not mini) is a full browser which you can install various handsets, including Android, Nokia and Windows Mobile.

Opera Dragonfly debugging tools support remote debugging on the mobile devices. You can use desktop debugging tools to inspect a page running in a mobile phone. A very handy feature for all mobile web developers.

5. Firefox Mobile (a.k.a. Fennec)

You can install Firefox Mobile on Android devices. There also exists community maintained port for Meego mobile platform and unofficial builds for iOS and webOS. The current builds use native Android UI and mobile optimized version of Gecko rendering engine. For more complex (web)  pages the speed of the browser beats Android Browser stock browser. Firefox Mobile is also the only currently shipped mobile browser supporting WebGL.

Image

A Firefox Mobile PC built exists for Microsoft Windows, OSX and Linux and is suitable for testing purposes. Note that some effort might be needed to make it run,  as these builds are not officially supported.

Download instructions for PC/Mac:

\"\" Subscribe to RSS feed Image Follow me on Twitter Image Follow me on Facebook Image Follow me Google+

Building commercial grade mobile applications with Python for Series 60

Posted on by
11

ImagePython programming language, created in 1991 by Guido van Rossum, is the sixth most popular programming language and “the programming language of year 2007“. Nokia Series 60 is a Symbian-based mobile phone platform for high end smart phones which is the most widespread smart phone platform. Python for Series 60 is Python ported to S60. PyS60 is open source and there already exists a notable community around it – a sign of a successful software platform.

This essay is a post-mortem for creating a commercial grade PyS60 application. By “commercial” I mean something which is publicly available for end users and meets the criteria of Symbian Signed certification. I hope this essay will shed light on the real world challenges, thus aiding Nokia, mobile application vendors and PyS60 community to know when to use PyS60, to strengthen PyS60 as a platform and to guide people make most of it.

Description of the project I was given a task to create a mobile phone client for a web service. The client runs on the the background, posting information from the phone (files, location) to the web site. Two developers were assigned for the job. In the end of the project, almost 100 Python modules and classes had been written (just for the mobile side of the things). I believe this is the most complex PyS60 development effort this far.

The application is divided in two parts: user interface process and background process. The background process is running all the time, monitoring the phone state and posting changes to the server. The UI process can be launched from the phone menu and it commands the background process. Two processes communicate over localhost TCP/IP sockets. The application communicates with the Internet server by HTTP multipart posts. The background daemon had four threads running: main thread, server communication thread, interprocess communication thread and GPS thread.

The core modules of the application were written portability in mind. In fact, one can run the core as standalone Python application on a normal PC. This makes unit testing and debugging much easier. Some supporting libraries and files were ported from the normal Python 2.2.2 distritbution to PyS60.

Python for Series 60 and the alternative platforms

When we started the project, I was not aware of commercial applications built on PyS60, besides Nokia’s own Mobile Web Server. I knew it was used as in-house in few large software companies. Python has traditionally had strong foothold in the academic world. So it does not come with a surprise that Finnish universities use PyS60 on mobile application software development courses due to Python’s low learning curve.

Python itself has been around longer than the most popular programming language, Java. Python’s suitability for the complex development jobs was largely untested until the rise of modern web. The dynamic, agile, nature of Python does not come for free. So called abstraction penalty (interpreting) slows down Python execution speed. It was not until the 00s when processor were fast enough to make this irrelevant matter: software development costs outrun hardware costs and more agile development tools had to be found.

When building S60 applications, you need to chose the progamming language between three candidates: Good old fashioned C++, Java Micro Edition (Java ME) and Python for Series 60.

Currently, most of Series 60, and Symbian, platform specific applications are written in C++, with a twist. One cannot consider this as “normal” C++ code, but the bastard child of this language. In their quest for the ultimate embedded efficiency (read: the smallest memory footprint) Symbian architectures placed an enormous mental burden on the poor Symbian developers. For example, Symbian C++ has custom pointer schemes, manual error handling, wicked threading and a weird build process. Or to put it bluntly: writing C++ for Symbian is far more difficult than writing C++ for platform X. You cannot really use any standard libraries on Symbian (this is changing, however). Thus, building S60 applications based on C++ technologies is costly, and painful. I have not yet met a happy Symbian C++ developer and I have met hundreds of them.

Then, we have Java ME. Sun made a good move by creating a unified mobile application run-time environment. Java ME is the only way to get your mobile application running regardless of the mobile phone vendor. But Java’s infamous slogan “write once, run everywhere” doesn’t hold a candle.Java ME implementations have internal differences and they are buggy as two weeks dead squirrel (seen one squirrel once and followed Sun’s Java ME mailing list long enough). Java ME gets the new features last due to standardization process. Java ME applications are heavily sandboxed and they cannot access half of the phone features.

And as the last option is Python for Series 60. Started as a Nokia’s research effort, Nokia brings this agile environment to mobile software development. Python for Series 60 has also a sister project, PyUIQ, which targets Sony-Ericsson phones.

PyS60 has had the reputation to be “prototype only” technology and it’s use has been counter-argumeted by “serious development needs C++”. This is slowly changing. Nokia has shown serious commitment to Python. With the launch of Mobile Web Server, Nokia proved that Python is feasible in commercial grade applications.

This is how my brain worked when I chose PyS60: Symbian C++ is notorious difficult and no sane person wants to ever touch it. Java ME might have not enough access to the phone features to fulfill the application requirements My client already used Python on embedded Linux and web servers. Why not give PyS60 a shot?

Arguments for Python for Series 60

Python is agile

This is maybe the most important argument to pick PyS60. Python tends to reduce development time compared to C++ or Java. The language itself is very easy to learn. Syntax is expressive and developers can achieve much more functionality in less lines of codes: You can focus on getting the task itself done. With higher level concepts and less hassle with lower level things, changes to introduce bugs radically decreases.

Python development does not have traditional compiling phase, though byte code files can be built for the final release to obfuscate the code and optimize loading times. Changes made into Python code are immediately (in seconds) visible in the running application. Even if the application runs on the target device, since code changes can be automatically synchronized over a Bluetooth connection. No wonder Python enjoys legendary fast prototyping language fame – the developers have less time to surf in web when they don’t need to wait compilers to bake yet another test build.

PyS60 is open source

I assume you are familiar with the benefits of open source already: vendor freedom, no licensing cost, not being mercy on others and so on. This all holds true for PyS60 as well.

PyS60 license (Python license) does not place restrictions for creating closed source software. You can have very good development tools for free: Series 60 SDK, Eclipse IDE with PyDev plug-in and PUTools bluetooth synchronization kit for free. This makes the barrier to enter PyS60 development very low.

Since PyS60 is fully available in the source code form, you can customize and fix it for your needs. The traditional horror story from Java ME development is that your application won’t run in the mobile phone model X, since there is a bug in the vendor’s Java Virtual Machine implementation. Unless you are A Very Big Player, don’t ever think about going to talk with the vendor and ask it to fix its bug – hitting one of these issues might prevent you to release product at all. With PyS60 you can control all aspects of the software execution up to the closed parts of the device. No more being mercy on others!

Being open is pop now. Embracing open source gives much for your company: good citizen reputation, hiring pool and free marketing.

Python is portable

Python runs on Linux, Windows mobile and Symbian – Python runs on almost every smart phone known to man. And not just the phones, it runs on every computer as well: Windows, OSX and Linux server and desktops. Moving your code between these environments is easy. Maybe there isn’t yet “cross-platform Python SDK for mobile phones”, but it might be just a matter of time when something leveraging the idea comes out.

In our project, core files, independent from graphical user interface, were built and unit tested on Linux desktop environment. No emulator was needed. It was not until the late development stages when they had to be moved to Symbian environment. Since you can develop and debug your code in such “easy” environment, you can work more effectively.

Because the full Python is available in the phone and it can run the exactly same modules as your servers, sharing code between these two environments opens possibility for making “smart” clients. Think about the situation where your phone is offline. It can have a subset of the full database loaded on a memory card. Since moving Python code from the server to the mobile is easy, the mobile application can have the same database functions and application logic modules loaded with it. Without the extra duplication of the logic code, one can operate on the small subset of the data and later synchronize it with the main database.

Python is extendable

You can mix C++ and Python. When you run out of ready components or you need unleash all available CPU cycles for CPU sensitive calculation tasks, you can write your own native extensions (DLL files) for PyS60 in Symbian C++. They enjoy all the same privileges as any native built code or application. Actually standalone PyS60 applications are just normal Symbian executables which just happen to have Python interpreter started inside them.

If you are working with phone features which are not yet very common and lack working Java ME implementations, say acceleration sensors, instead of creating a native C++ application you can create a Python application. You need to mix-in low level C++ only for the the critical part of the applications which operate with the native platform API.

PyS60 community is vivid

Surf to forum.nokia.com Python discussion boards and you can witness the activity around PyS60. A lot of folks are answering the beginners’ questions and guiding them. If your case is not totally unique, you can expect help to be found. As a matter of fact, you, reading this text, is a sole proof of powerful community. I was not directly paid to write this and I am not affiliated with Nokia any way – this writing flows from the bottom of my heart to promote PyS60 and open some window for the (hireable) talents of our company.

You love it

For some things, we just feel impulsive attachment. They are beautiful, aesthetic, sexy. When you see it, you need to have it. PyS60 is one of these things.

Arguments against Python for Series 60

PyS60 has not been around for long

PyS60 is a young project. It still has some maturity issues. If you don’t do preparations well and test that all needed modules work as you want them to work, you might need to do some extra work to get around the issues.

Especially PyS60 user interface lacks some crucial components and polish which may force you to create UI components yourself.

By “getting around” the issues I mean leaping to the native Symbian code world and writing embedded C++. Since this leap is all but a little step, in the terms of development skills and complexity, I recommend preparing for the worst before the roof is falling on your head. I have seen too much “plz reply me asap urgent my boss kills me this afternoon” PyS60 discussion board messages from persons who haven’t done their homework. For example, you could make sure that you have some hired Symbian guns available in the case your own effort was not enough.

Python is for high-end phones only

PyS60 and PyUIQ are available for the high end smart phones only. Nokia’s Series 40 devices, and other devices built around in-house operating systems, cannot run Python. If you are targetting to e.g. consumers markets and Java ME has all the required capabilities to implement the application, it is the only real way to go.

Symbian is dreadful platform

Symbian, as a software development platform, is very challenging. Due to its history, the feeling of developing for Symbian differs greatly from other mobile, desktop and server platforms. Things simple elsewhere, like installing an application, might become a development nightmare on Symbian where one has to fight his/her way through capability limitations, artificial device restrictions and signing process just to get the application to the phone.

PyS60 naturally inherits all these challenges. Java ME goes around the issue by having its own custom installation, signing, etc. schemes. On Symbian, even accessing some of the device features – a device you own and hold in your hand – requires you to throw in few hundred bucks cash to get the publisher id – to get the developer certificate – to sign the application – to have all required capabilities – to access the specific features (read: GPS). More cash and third party testing is needed to publish the application. This is the price of virus free DRM’ed platform.

Lack of entrepreneurship spirit

If your company states “we are a Java house” or “we are a C++ house” and you miss courage to look for alternatives, then maybe you shouldn’t. Sailing into the brave new world takes more resources than staying near your home harbor. On the other hand, if you are a technology company, it’s quite important follow technologies outside your mainstream, unless you want to suffer the extinction when the new kids on the block gain power (remember the day when COBOL died).

Conclusion

Nokia has done a great deed and effort by creating PyS60 and then giving it out for us to play. Now its own turn to act as a community to give back something we can.

Building commercial grade PyS60 applications might not be straightforward yet, but it is possible. Working with PyS60 is definitely more productive than using complex Symbian C++. It is not always straightforward as Java ME, but eventually it will be. Not only that, but PyS60 can surpass Java ME development with all the Python’s agility.

If you consider PyS60 for your commercial grade product, it all boils down to the feature set of the application, your existing team skill set and the hacker spirit. And now there exists at least one commercial vendor, besides mighty Nokia, who advertises commercial PyS60 services (hint: our company), so you won’t be alone.

We could look things in a larger perspective. In the mobile world, PyS60 is the pack leader of Python-in-your-pocket solutions. Windows CE has Python support available, but it is not officially backed up by Microsoft. This may change quickly when mobile .NET virtual machine gets DLR support making it possible to run IronPython. On Linux platforms, Python is a natural part of the platforms (OLPC, OpenMoko). Google Android and Apple iPhone will roll out their own software development platforms soon.

In the dream world, we could have a common mobile Python platform akin to Java ME of today. Java is not the only way to provide vendor neutral mobile applications: there already exists effort to get mobile cross-platform .NET implementation (Mono on embedded Linux, Red Five Labs .NET on Symbian). The future popularity of Linux phones, iPhone and Android might decide the faith of mobile Python. Could we have Python as a batteries-included feature in the future phones?