Revived an old project of mine: TKMacTuning

I'd like to introduce you to a long forgotten project of mine...

TKMacTuning aims to help you configure Mac OS X. It is written in Java/JavaFX and is published under the terms of the GNU General Public Licence version 3. I started working on TKMacTuning in 2008, but it soon got buried under a pile of other projects. Originally the app was planned to use Swing accompanied by the reference implementations of JSR-295 (Beans Binding) and JSR-296 (Swing Application Framework). You still can see that in the earliest commits. Sigh. Those were the days... Anyway, sometime I decided to do some JavaFX programming. I figured it might be a good idea to revive the project.

So, what does TKMacTuning do?

A lot of configuration in Mac OS X is done using a defaults database. There is a commandline tool called defaults to access it. The command is used as follows: defaults read com.apple.screencapture disable-shadow displays a particular setting. write changes values and delete removes entries. TKMacTuning will put a nice user interface on top of this. So you can change settings with checkboxes, comboboxes and file dialogs. Under the hood, the commandline tool is accessed.

So far, just a few settings have been implemented. The ones you see in the screenshots do work, however. In the coming months I hope to expand the scope significantly. For example, you will be able to change the login background window and configure the login screen. The ui will get nicer, too. Anyone interested in participating is more than welcome to clone the repo at GitHub.


The story so far...

Quite a lineup, isn't it? And there is more to come this year...
Tommis books


Thoughts on the mobile enterprise #9: Long term strategy

In a series of posts I will elaborate on how enterprise applications can embrace mobile devices.

In part 8 we took a look at factors influencing the decision whether to make or buy a mobile app. I concluded by saying that the long term strategy of an organization has great influence on that matter.

Who can define the long term strategy of an organization primarily depends on its legal form. If the organization is an ordinary company, its destiny is ultimately controlled by the owner. He, of course, may delegate the task. This is also true if the ownership is shared among many people, as in corporations. In such scenarios, we usually find a chief information officer, who is in charge of everything related to information technology. Though he is not responsible for the long term strategy of the organization as a whole (which would be the chief execute officer), he needs to make sure his decisions comply with it. This might mean answering the question whether to build mobile apps.

The situation may be a little more complicated if the organization is public, such as authorities. Their organizational structure is determined by law, as is their long term strategy: public institutions are not supposed to make money, but to fulfill a specific purpose (for example ensuring the welfare of the people). Still, larger authorities do have chief information officers these days. Now, would he decide if his organization should build mobile apps? To answer that question, let us think about the term long term strategy a little bit more. 

For an ordinary company it might mean increase the market share by 5 percent within the next five years. How this can be achieved depends on the product the company is selling. If that is traditional desktop software, the company must seek new platforms, since the number of new personal computers being sold has been shrinking for quite a while, whereas smartphones and (to a lesser degree) tablets still sell like hotcakes. So, yes, that company should build mobile apps.

How about authorities? Here, part of the long term strategy might be increase the quality of service by, for example, making it easier to contact staff or to check if a claim has already been decided. It certainly makes sense to offer filling in forms or tracking status electronically (over the web). But does there have to be a (native) mobile app? I am by no means implying that there should not be one. I just want to stress that there has to be someone who weighs the benefits (increased level of service) and the costs (for developing the app).

To sum up, the long term strategy of an organization determines where the organization whats to be in five or ten years. This may have great influence on product development, recruitment and training of the personnel. It most certainly influences the decision whether to deal with mobile apps. Whether this means making or buying, has to be decided afterwards.


Thoughts on the mobile enterprise #8: Make or buy

In a series of posts I will elaborate on how enterprise applications can embrace mobile devices.

In part 7 we took a look at different types of apps, in particular apps for employees. In this post we will focus on one of the most crucial yet underestimated questions: should a mobile enterprise app be developed in-house, or should development be outsourced?

Developing software on a larger scale requires a lot of processes be established and a lot of prerequisites be met. Consider these questions:
  • Are there enough people with the required skills available to develop and maintain the software?
  • Is a software development process in place, including guidelines, best practices and regulations?
  • Do developers and testers have access to required hardware?
  • Is the required hardware properly integrated in the overall infrastructure?
  • Are all necessary tools available?
  • Are all formal and legal prerequisites for bringing software into production met?
If an organization has already established development teams and corresponding infrastructure, those questions can probably be answered with yes. But what is true for traditional enterprise application development need not necessarily be the case for mobile enterprise app creation. Think of this: to build a native iOS app and to test it on a device you will need a Mac. Developers targeting Android may choose from a broader range of development machines, but if the infrastructure team decided to lock the usb ports, they are out of luck either. More on this later.

 Now, what factors do - or should - influence the decision whether to build a mobile enterprise app or to buy it? Take a look at this deliberately unordered list:
  • Time to market
  • Criticality
  • Dependency
  • Cost
  • Available skills
  • Long term reputation
  • Requirement
  • Perception
  • Strategy
Let us translate these words into pairs of questions:
  • Is it important to bring the app to market as fast as possible? Or is it vital to be best in class?
  • Is the release of the app an urgent necessity? Or is it more important to demonstrate ones capabilities?
  • Must development costs be as low as possible? Or are other factors more important?
It is clear that there is a tension between those factors. They influence each other. For example, although time to market and overall costs may suggest outsourcing development, the long term reputation (We did the app on our own) may be more valuable, even if this means setting up a mobile dev team from scratch. The other way round may also make sense, however: even if a team is capable (in terms of skills) of developing mobile enterprise apps, it simply may not be worth adapting processes, investing in infrastructure or tools, establishing rules and regulations, if that one project is expected (or wanted) to be a mayfly.

I am by no means implying that outsourcing development is necessarily cheaper than doing it in-house. Here, it serves only as an example. A valid and serious comparison of the costs has to take into account lots of figures, for example the organizational structure of the company, the subject (the app) and of course the offers of potential contractors.

The most important driving factor for mobile in-house development is the long term strategy of the organization. We will hear more on that in a later episode...