Feb 29, 2012

Feb 23, 2012

Storing TypoScript in the file system

There was an interesting question in the TYPO3 mailing lists: “How do you store TypoScript?”. Here is how I do that.

I store TypoScript in the file system. There is a main file, which is included to the site TypoScript template using statement. This file contains statements to include other files.

Other files are created logically, per feature or group. For example, I usually have:
  • constants.txt – sets all constants
  • config.txt – includes all “config” settings (such as “config.absRefPrefix”, etc)
  • page.txt – creates PAGE object, including “page.headerData”
  • seo.txt – all SEO options (some “config” settings come here)
  • news.txt – includes the news plugin I use
  • home_page_objects.txt – all TypoScript object, specific for home page
  • ...and so on.
Plugin files (such as “news.txt”) also include files from corresponding extensions using . “Include static (from extensions)” is empty in the TypoScript database record. That allows granular control on all included files. TypoScript from the css_styled_content extension is included into “page.txt”.

I avoid having multiple places for the same set of options. For example, all news settings will be in “news.txt”. The only exceptions are:
  • seo.txt, which contains certain SEO options from “config”
  • “page.headerData”, which can appear in other files as necessary
However, “plugin.tt_news” will never appear outside of news.txt. Thus, if I need to choose news settings, I always know where they are. Also I can replace news plugins or remove it completely as necessary.

The buggest advantages of such approach are:
  • It is versionable. I use Git to store projects and store TypoScript in Git.
  • It is very clean and clear. I always know where the stuff is. Any new maintainer will be able to see it too immediately.
  • It allows to customise, replace or remove features very quickly.
If you have your own practices, please, share in comments.

Feb 22, 2012

Apple integrates Vimeo to Mountain Lion instead of YouTube

Apple integrates Vimeo to Mountain Lion, skips YouTube. This is interesting news, which shows several important signs to us.

Firsts, Apple does not follow trends, it creates trends.

When Apple refused to support flash, many saw this like an obvious fault, which would seriously decrease ratings of iOS. That did not happen. Flash came to Android but was unusable. In the end both Adobe and Google abandoned Flash support for mobile devices.

Secondly, if the service is absent on iOS, it looses a lot of audience.

While Facebook is a huge web site, it is not really present on iOS. Due to unknown reasons Facebook and Apple did not agree on Facebook integration to iOS. As a result Apple integrated Twitter support to iOS, which gave Twitter a huge boost: lots of twits now come from iOS devices. iOS is also known as the OS, which makes the most of Internet traffic these days.

Thirdly, Google should not have fought Apple.

When Google decided to make a concurrent product and hired a former Apple employee, who was working on iPhone to create Android, this was unfair. Apple now ignores all new Google services and includes products from alternative solution vendors. Twitter instead of Google Buzz, Vimeo instead of YouTube.

Will Apple remove YouTube and Gmail support from iOS?

I do not think this will happen soon but it is likely. Apple becomes more and more agressive in defending its inventions, so I do not see why they would promote competitor's services any more. Personally I have nothing against Google (I like Gmail) but Apple may think different.

We can also remember a huge scandal when Google cheated on Safari users, implementing workarounds for Safari privacy policy to avoid cookie blocking by users. Not nice at all.

“If you are against us, you are not with us”, that's current Apple policy. If somebody acts against you, you do not have to be good to him. Sounds natural.

Feb 16, 2012

Jedi programmers

There are three levels of coding that you can master: dumb, professional and jedi.

Dumb level is for those, who go for straight solutions, who never learn anything new, who do not care to find a better solution that they already know. Dumb programmers are best seen when they receive a bug report. Upon receiving a report, they start adding messages to the web page content at every possible code point, including points that are far from the cause of the problem (meanwhile visitors wonder what does that rubbish mean on the site). Sometimes dumb programmers just go and “fix” the issue by making the straightest, fastest and dumbest solution possible: the solution, which is neither good, nor it is entirely correct. Fixing typically happens on the live host and disrupts host's work with error messages and down times. Well, it is dumb.

Professional level is for those, who understand the importance of learning, the priority of the quality and that the first solution is not necessarily the best one. When it comes to bug fixing, they realize that to fix the issue, they need to find its cause. Professional people typically investigate first. Often they use developer's log, debug messages that are visible only to them or a debugger. People, who mastered the debugger, usually figure out the cause of the bug faster. Next they try to resolve the bug in a good way. Professionals do not take the first obvious approach but try to evaluate it from all sides and see the consequences of their fixes. They usually work at development host and choose to integrate their changes to the live environment with no or minimal disruption.

Jedy never do like dumb people but they often do the same as professional people do. Often, but not always. For example, with bugs a jedy can investigate the bug by just clicking and looking. Often they do not need to use the debugger or debug messages at all. And here I can't resist posting a quote from a sixth Harry Potter book: