Living in Hungary, which is a country located in Central-Eastern Europe, and being a part of the EU can be such a weird experience.

Globalization, the internet, outsourcing, trends like these enabled us to work for international companies, allowed us to read sites, magazines, follow blogs like anybody would do in Western Europe. Being the citizen of the European Union, and having access to the same information as anybody else in the EU makes us want to consume the same things.

Our expectation is to watch movies at the same time we read about them on movie blogs, we would like to purchase games that game sites talk about right now, we'd like to download music that shows up on rollingstone.com, NME or Pitchfork reviews, we'd like to IMPULSE BUY online like anybody else with the same taste and budget.

Not only this is not happening, I don't even see any trends that would change the situation. The major online music stores like iTunes or Amazon do not sell to CEE countries, console gaming download stores like the XBox Live Marketplace, the Playstation Network Store, or the Wiiware/DSiWare stores from Nintendo do not allow purchase using a Hungarian registration and a Hungarian debit or credit card. We don't have Amazon Kindle store access. Basically the only major, international entertainment content provider is Apple with a Hungarian AppStore here, only providing iPhone and iPod apps, not music or movies.

There are many reasons companies use internally or externally about why this is happening, some of them:

  • Copyright is not managed and controlled centrally within the EU, agreements have to be made with local copyright management groups
  • The standard of living, and with it, entertainment budgets tend to be lower in this region
  • Localization costs money, it takes a budget to create a translated, localized store front, and it costs money to provide support and maintain the sites
  • Piracy is a big issue, people have ample access to movies, music, games for free

My opinion is, while these points are valid, in the end, all these companies essentially turn down free money in a globally shrinking economy and a significantly impacted entertainment market.

Copyright

While the EU is talking about working towards a single copyright solution across the EU, companies should work extra hard to accommodate these new markets, and enable rightful product purchases instead of driving more and more customer generations toward piracy themselves. Force the major content providers (game publishers, major labels) to sign EU-wide publishing contracts for these online stores.

Market size

The recent recession seems to become an equalizer, wiping out family entertainment budgets worldwide. I suspect this will even out across the EU within a few years. Reuse the marketing budgets, the videos, ad campaigns EU-wide, we don't expect any specific local messages.

Cost of localization

Virtually everybody I know who wants to have access to this digital media would be just fine with non-localized store fronts and non-localized content. We all speak English and we're used to this. Add to the Terms of Service we need to accept that support will only be provided in English or German or whatever, we can deal with it. If the market becomes significant enough, localize things step by step.

Piracy

Piracy is a classical chicken-and-egg problem across the region. It will obviously not change until we have equal ease of access (and equally reasonable pricing) to legal content. There is no other way to turn the tide: publishers need to provide quality and quantity online, make it possible to buy!

By ignoring these markets, publishers and online platform providers risk losing new generations of consumers forever. I applaud services available to us, like Valve's Steam online game store service, the Apple AppStore, and the EU-wide World of Warcraft service. I don't think it required a major investment from them to accept my Hungarian card. I suggest a similar approach to Sony, Microsoft, Nintendo, Amazon, etc. Just let us give you money!

I was quite excited to hear about Google's hosted application platform. I grew somewhat tired of my home project setup, which is PHP/MySQL located at a shared host. The Google App Engine seems like an ideal environment for me to do some educational hacking, without having to bother with the software and hardware infrastructure, great!

Although I've been looking at Python for a number of years, I've never completed a serious project with it. I'd be probably more ready to work with Ruby or even Java. Still, Python does seem to be the right language for the platform. It's a modern, dynamic language and has an established, extensive set of class libraries for nearly every need. Though only Python-native libraries can be used on the App Engine, there are still thousands of readily available modules to work with.

It's interesting how Google customized Python 2.5 for the App Engine to keep it safe and control its resource impact. Threading, spawning sub-processes is disabled, there's no socket or file access, and each process must terminate within a time limit, otherwise it is shut down. These limitations make sense, they need to keep shared hosting viable. By locking down potentially troublesome areas, it's not up to the individual developers to manage the resource consumption in check, it's the safest route. On the other hand, it'll be interesting to see how seriously this will impact the development of a relatively complex application.

Although developers can work with a number of native Python Web frameworks, I've decided to work with the built-in frameworks, to minimize the hassle of configuring and debugging stuff. It took me about an hour to get the SDK, install it, and watch the demonstation video. This is what I've achieved in about 4-5 hours of hacking afterwards:

1. Setting up URL Handling

I've structured my web application into three separate sites, under three URLs, one area for public access, one back-end site for authoring, and one administrative website. I needed to configure the web application to handle these separately.

There are two discrete layers where URLs are handled. The initial configuration is managed in the app.yaml application configuration file, like this:

- url: /index\.html
script: home.py

- url: /admin/.*
script: admin.py
login: admin

This maps specific URL patterns to the Python scripts that will handle them, and configures authentication as well. It's fantastic just to declare the login attribute, and get the whole login, logout, registration process from Google Accounts.

Developers are able to fully configure URL handling in the yaml file, however it makes sense to dispatch the individual Actions users can do on the specific area of the site through the provided Python WSGI framework. After the request is routed based on the URL pattern, the Python script where the request was routed to is able to process the request further, and instantiate specific classes for specific operations.

Dispatching requests

In this example, the /author URL pattern is mapped to author.py, and within the author.py file, the actions are dispatched to individual classes (which can be implemented in external modules, or within the main .py file).

2. Displaying content, templates

Once the requests are dispatched to classes, the post or get functions are called on the class, depending on the type of HTTP request. Not surprisingly the function will have access to all the request variables, and will be able to output the response through a simple self.response.out.write() function. Any reasonable complex web application will probably need more than that. Instead of developing yet another web templating application, Google decided to bundle the (quite decent) templating module from the Django framework.

Template handling

Basically you can set the dynamic data into variables, and pass them into a HTML template through this framework. Within the template, lists can be iterated, there are conditional expressions available, and you can even invoke functions.

HTML example

It's not a tag-based template engine, but it's quite easy to read and author.

3. Working with the datastore

One unique aspect of the Google App Engine is that Google's BigTable platform is provided for persistent storage. This is extremely cool as us developers get the same highly scalable, high-performance data store that many Google Apps use. It is however not a traditional relational database, so I had to read up on it for a while to figure out how to use the API. It is not difficult at all to quickly create Model classes, add various attributes, use the GQL query language to do selects, and create new persistent items through simple put() methods. I'll however need to spend some more time to understand how to handle relationships by adding ReferenceProperty type attributes to the model classes.

Overall I don't think I'll have problems with the Datastore API, but so far this API had the biggest learning curve for me.

4. Deployment, hosting

I already had a registered domain for the project I plan to implement on the Google App Engine platform. It took a little while to find the proper docs about how to set it up:

  • I had to register the domain within Google Apps for Domains
  • Then once the domain is registered for Google Apps, I needed to configure a verification CNAME within GoDaddy's TDC management tool.
  • Once the domain works within Google Apps, the App Engine application can be configured to work with the domain through the Console, in the Administration/Version section.
  • The wizard that leads through the process of configuring the domain has one problem - it does not display the additional step required to configure the "A name" for the domain. Luckily I've found the FAQ for this.

So I now have a few working pages, querying and persisting data into the Google Datastore, configured for the proper domain. It's been a blast to work with this. The local development environment is great (which I use with TextMate as an IDE), the documentation and the examples are a decent starting point, and it's very easy to deploy the code onto the hosted environment. I'll try to finish this application in the next few weeks, and will report on my progress through this blog.

This week I had the chance to travel to Barcelona, as a booth bunny at EPAM's stand in the Exhibitors area at BEAWorld.

I've been to a San Francisco BEAWorld as well as the one two years ago in London. This one seemed to be smaller in scope and especially the number of exhibitors and partners was significantly less. I guess the Enterprise space has been consolidating and shrinking in the last few years.

Obviously BEA is buying many of the companies building products and extensions on top of its platforms, like the recent acquisitions around portals (Plumtree), BPM(Fuego), commerce, Voip, etc. The other big vendors (Oracle, SUN, IBM) are also buying up some of the smaller players, which is probably a good thing, a sign of a maturing industry. It does however make a more boring and smaller ecosystem around BEA.

While mostly I was focusing on talking to visitors, I had some time to sneak into some of the keynotes and presentation sessions throughout the conference.

The opening speech by CEO Alfred Cheung I thought was on par with the previous ones. He's a well-trained, competent but unexciting speaker in my opinion. The only thing that caught my attention was his quite tough rally against enterprise software package solutions, and how these don't fit the current business environment of rapid change and agility. It makes sense to be aggressive and fight back, as these package vendors (SAP, Oracle, Siebel, etc.) are moving more and more agressively into the platform space, positioning their own portal and BPM platforms, even Java EE containers and SOA frameworks against pure-play platform vendors like BEA. It's smart to acknowledge this and fight back by relying on a promise of a flexible, adaptable, agile platform.

The other keynote I was really interested in was by Paul Patrick, Chief Architect of BEA Systems.

He's BEA's chief "SOA guy", coming from the AquaLogic product line into the Chief Architect position. He has an interesting podcast series at InfoWorld (albeit the reading-from-paper type). On his keynote, it was fascinating to listen to the overall architectural strategy, and I've learned concepts I'm sure I'll be able to use in various sales situations. I liked the analogy of "neighborhoods" for distinct logical subsystems in an enterprise, formed around corporate divisions or newly acquired subsidiaries with separate needs and IT infrastructure. BEA's vision on how to serve these loosely coupled enterprise neighborhoods through a "service fabric" sounds fascinating and tantalizing for large enterprises.

My biggest worry is BEA's insistence on providing simplicity through more and more complex product suites and frameworks. It's great that they realize the need to provide a simpler development and runtime platform for Enterprise SOA development. But layering more and more complex products and frameworks (especially through acquisitions of disparate product suites) creates a new landslide of complexity both in terms of development and deployment. The current "Project Genesis" vision looks extremely appealing, and the ability to quickly and painlessly assemble and deploy new services makes a fantastic sales demo, but I'm not sure if this complex assembly of ESB, BPM, Portal, Security, "Web 2.0" products will just blend in this seamlessly.

BEA does have the engineering capabilities to provide a seamless integrated experience for complex problems, WebLogic Workshop 8.1 did prove me that a good few years ago. I have a good opinion on most of the individual products the new strategy will be built on. BEA's biggest challenge will be to take these different products, make their management, development, deployment interfaces as similar as possible, and to simplify aggressively, even at the cost of losing features. Perhaps moving these products to the new, more lightweight OSGi-based Server core will be the strategy to achieve this.

We don't really have many developer-focused conferences here in Budapest, so even though I'm more of a Java/Ruby/Open Source guy, I was really psyched to visit the Microsoft REMix'07 conference.

Not only I had a good time at the main event, I was lucky enough to have an open discussion with one of the key .NET guys at Microsoft, Scott Guthrie. The focus of the conference as well as our discussion was the recently unleashed Silverlight browser plug-in from Microsoft.

I've recorded about an hour's worth of a really interesting, engaging discussion with Scott, who is the GM for the Developer Division at Microsoft, Beau Ambur from Metaliq, and Pete LePage, a Microsoft Product Manager for Internet Explorer.

Although I did not have the chance to unpack and build up my "proper" audio recording kit, I think the recorded audio is good enough, I'd recommend anyone interested in Web technologies to have a listen.

Here's Part 1 of the discussion, where we're talking about:

  • Scott's blogging habit, cats, wives
  • Silverlight - is it a replacement for HTML?
  • Why would I select Silverlight vs. Flash
  • Silverlight 1.0 as a media platform, what's coming up in 1.1
  • LINQ as a query API, is it "The One" data access API?


As time permits, in the next few days I'm going to edit the other 2 or so segments and make it available here. You can subscribe to my podcast feed at feeds.feedburner.com/tentimes to get the other segments automatically.

With all these recent announcements (Microsoft's Silverlight, and Adobe's Flex push), I have the following vision of "The Web" for the next 2 years or so:

  • Every self-described designer and web developer will have a powerful toolset to design and implement highly dynamic, rich UI with animations and video for the web
  • These new websites will look like those ridiculous "multimedia" CD-ROM products 10 years ago
  • Navigation, bookmarking, linking will not work, it will be inconsistent and badly implemented
  • All the advances of CSS-based, mobile-adaptable, clean XHTML pages will be gone for these new "rich" websites.
  • You'll have to support your mother and your extended family to troubleshoot broken browser plug-in installations

But this is all OK. Eventually new standards and best practices will emerge, and we will figure out ways to make the new "rich" web experience reasonably consistent and usable.

Link: http://fb2.hu/x10/Articles/FlashLiteDev.html

Mobile applications still seem to be just about to happen. Every year there are some great advances in the underlying network, data transfer is faster, devices are smarter, more consumers buy them, and even the providers seem to come up with reasonable data rates. Customer interest seems to be the last (and biggest) battle ground, and this year it’s the iPhone that makes me hope again that people realize the power of the little devices they’re already carrying with them.

Read my article on how to develop mobile software using Adobe's Flash Lite mobile platform, and how it compares to other development platforms.

1 2 3 4 5 6 >>

April 2014
Sun Mon Tue Wed Thu Fri Sat
 << <   > >>
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30      

Search

Random photo

XML Feeds

powered by b2evolution free blog software