Not everyone has a smartphone, and strange as it may sound for those who can't live without their mini call-placing computers, avoiding an US$80 to US$100 monthly data plan is often driving that conscious choice. But it is possible to get a data add-on to a cell phone plan for as little as US$10 a month. For that set of in-betweeners, a program like Snac could bridge the gap between a modest data plan and accessing Web content like social network feeds and news stories.
Snac, in open beta, provides a dashboard of thumbnail-size widgets that periodically grab content from Facebook, Twitter, Gmail (POP3), the weather, Google Calendar, news sources, and so on. Snac precaches a few layers of content, so that when you click a widget, you'll be able to immediately see headlines, status updates, and so on, on a small pop-up window.
Snac isn't just read-only either. For instance, you're able to update your social networking status and add comments in Facebook. Ditto with Twitter, but Snac isn't equipped for direct replies. Opening a news story pushes you to your phone's default browser, but Snac CEO Mark Caron tells us they'll soon add an in-app browser for reading purposes. At this point, you're unable to configure how often Snac pulls in fresh content, but Caron says they're looking into that, too.
Caron demoed Snac beta on a Sony Ericsson TM 506 phone, and a private beta version for BlackBerry. It works on almost 300 Java feature phones, but also on Symbian and Windows phones. There's no limit to how many widgets you can install from the Snac gallery, and managing the dashboard is straightforward from the phone settings and from the Web.
The free, ad-supported app isn't much of a looker, with a boring background, blocky typeface, and sketchbook widget design. But it worked quickly and well in our demo. We'll be keeping an eye out for future developments.
Monday, October 12, 2009
Sunday, August 23, 2009
Oracle gets go-ahead to buy Sun
The US Justice Department has given its approval for business software firm Oracle to take over computer hardware software maker Sun Microsystems.
The $7.4bn (£4.5bn) deal was agreed by the two in April this year, but still needs approval from the European Commission before it can be concluded.
The acquisition gives Oracle control over Java, a key programming language used in its products.
The takeover had been held up over questions about licensing Java.
The language is used in billions of electronic devices across the world.
The deal is expected to be finalised at the end of the summer.
Oracle is looking to strengthen its position against rival IBM, which abandoned its own attempts to buy Sun earlier this year.
Sun employs about 33,000 people, while Oracle's workforce totals 86,000.
The $7.4bn (£4.5bn) deal was agreed by the two in April this year, but still needs approval from the European Commission before it can be concluded.
The acquisition gives Oracle control over Java, a key programming language used in its products.
The takeover had been held up over questions about licensing Java.
The language is used in billions of electronic devices across the world.
The deal is expected to be finalised at the end of the summer.
Oracle is looking to strengthen its position against rival IBM, which abandoned its own attempts to buy Sun earlier this year.
Sun employs about 33,000 people, while Oracle's workforce totals 86,000.
Friday, July 31, 2009
How SpringSource is taking on Java Goliaths
Some argue that open-source software can't innovate. In fact, one of the industry's former executives, Peter Yared, recently argued that "the only successful open-source companies sell commodities."
Yared clearly hasn't heard of SpringSource, an open-source application platform provider that is redefining the J2EE application server and, quite possibly, the future of open source.
Yared isn't alone in his beliefs. A friend recently wrote me to suggest that open source is at its best when disrupting big, profitable markets:
Commercial open source is a (commodity) replacement market. When it is not (i.e., people are building new, never-done-before cool/future-proof apps with open-source technology), then it is a pure-play Internet-based business model, one that is becoming so specific/demanding that people will want full control and (to) develop their own stuff, e.g., Google, Facebook, and others that heavily use open source to build their Web services.
SpringSource and its ubiquitous Spring Framework, however, promise something different. Something much more ambitious. Not only does Spring challenge the status quo in application development, deployment, and management (Hyperic), but SpringSource is proving that commercial open source can peacefully coexist with community involvement.
In a conversation with Spring creator and SpringSource founder Rod Johnson, he clarified SpringSource's competitive differentiation:
The essence of SpringSource is that we're not a commodity play but have a far more ambitious agenda. We're not interested in replicating what closed-source vendors already offer, at lower price: We are providing a superior experience to developers and operations teams--for example, in our integrated approach to unifying the application life cycle from developer desktop to the data center--which doesn't presently exist in Java.
Of course, our offerings are also leaner (more productive and faster), cheaper and more open than those of the old incumbents, and that's a huge selling point in today's market. But we're focused on being the enterprise Java leader--and not merely in open source.
(Credit: SpringSource)SpringSource isn't simply replacing IBM WebSphere, Oracle WebLogic, or Red Hat JBoss application servers. It is actually doing much more, and it offers, in my opinion, the best example of just how disruptive an open-source vendor can be precisely because SpringSource isn't seeking to be the open-source leader in Java, but the leader, period.
Gartner estimates that there are currently at least 2 million Spring developers, an impressive number suggesting that the Java community is looking to Spring to help it migrate Java applications onto lighter-weight containers (Tc Server), across highly virtualized environments, and ultimately to the cloud. Given SpringSource's strong financial performance, the company seems to be doing a good job of monetizing a significant percentage of that Spring adoption.
Yared clearly hasn't heard of SpringSource, an open-source application platform provider that is redefining the J2EE application server and, quite possibly, the future of open source.
Yared isn't alone in his beliefs. A friend recently wrote me to suggest that open source is at its best when disrupting big, profitable markets:
Commercial open source is a (commodity) replacement market. When it is not (i.e., people are building new, never-done-before cool/future-proof apps with open-source technology), then it is a pure-play Internet-based business model, one that is becoming so specific/demanding that people will want full control and (to) develop their own stuff, e.g., Google, Facebook, and others that heavily use open source to build their Web services.
SpringSource and its ubiquitous Spring Framework, however, promise something different. Something much more ambitious. Not only does Spring challenge the status quo in application development, deployment, and management (Hyperic), but SpringSource is proving that commercial open source can peacefully coexist with community involvement.
In a conversation with Spring creator and SpringSource founder Rod Johnson, he clarified SpringSource's competitive differentiation:
The essence of SpringSource is that we're not a commodity play but have a far more ambitious agenda. We're not interested in replicating what closed-source vendors already offer, at lower price: We are providing a superior experience to developers and operations teams--for example, in our integrated approach to unifying the application life cycle from developer desktop to the data center--which doesn't presently exist in Java.
Of course, our offerings are also leaner (more productive and faster), cheaper and more open than those of the old incumbents, and that's a huge selling point in today's market. But we're focused on being the enterprise Java leader--and not merely in open source.
(Credit: SpringSource)SpringSource isn't simply replacing IBM WebSphere, Oracle WebLogic, or Red Hat JBoss application servers. It is actually doing much more, and it offers, in my opinion, the best example of just how disruptive an open-source vendor can be precisely because SpringSource isn't seeking to be the open-source leader in Java, but the leader, period.
Gartner estimates that there are currently at least 2 million Spring developers, an impressive number suggesting that the Java community is looking to Spring to help it migrate Java applications onto lighter-weight containers (Tc Server), across highly virtualized environments, and ultimately to the cloud. Given SpringSource's strong financial performance, the company seems to be doing a good job of monetizing a significant percentage of that Spring adoption.
Saturday, June 27, 2009
Android goes beyond Java, gains native C/C++ dev kit
Google's open source Android operating system is maturing and beginning to attract a more diverse audience of third-party developers. To accommodate the growing need for more power and flexibility, Google is opening up the platform to additional programming languages and new kinds of development.
The Android userspace is largely dominated by Java technologies that run on top of Google's custom Dalvik Java virtual machine. At launch, Java was the only officially supported programming language for building distributable third-party Android software. That's starting to change as Google introduces new options. On Thursday, the company announced the availability of the Android Native Development Kit (NDK) which will allow developers to build Android software components with C and C++.
The NDK will enable developers to code some of the performance-sensitive parts of their programs in C and reuse existing C code on the Android platform. It comes with some limitations, however, and is not intended to serve as a full alternative to Android's Java development model.
The NDK does not provide access to platform framework APIs. It's intended to be used alongside Java to code individual parts of programs that require existing C libraries or higher performance. JNI is used as the bridge between Java and native code.
The NDK includes a cross-compiler toolchain for generating ARM binaries that can be deployed in Android APK packages. Google says that native code should be used sparingly and is not appropriate for the vast majority of third-party Android applications. The company also points out that using it could reduce portability and have other negative consequences.
"The NDK will not benefit most applications. As a developer, you will need to balance its benefits against its drawbacks; notably, using native code does not result in an automatic performance increase, but does always increase application complexity," the documentation says. "Typical good candidates for the NDK are self-contained, CPU-intensive operations that don't allocate much memory, such as signal processing, physics simulation, and so on."
In addition to delivering support for native code, Google is also extending Android to support popular dynamic scripting languages. Earlier this month, Google launched the Android Scripting Environment (ASE) which allows third-party developers to build simple Android applications with Python and Lua.
The ASE provides access to platform framework capabilities through a JSON RPC bridge. This means that scripts which run on top of the ASE can actually leverage other capabilities of the operating system, such as controlling the ringer volume, toggling WiFi, making calls, detecting the user's current location, launching activities, and handling intents. One of the most compelling aspects of the ASE is that it allows users to code new scripts on the device itself.
The Android userspace is largely dominated by Java technologies that run on top of Google's custom Dalvik Java virtual machine. At launch, Java was the only officially supported programming language for building distributable third-party Android software. That's starting to change as Google introduces new options. On Thursday, the company announced the availability of the Android Native Development Kit (NDK) which will allow developers to build Android software components with C and C++.
The NDK will enable developers to code some of the performance-sensitive parts of their programs in C and reuse existing C code on the Android platform. It comes with some limitations, however, and is not intended to serve as a full alternative to Android's Java development model.
The NDK does not provide access to platform framework APIs. It's intended to be used alongside Java to code individual parts of programs that require existing C libraries or higher performance. JNI is used as the bridge between Java and native code.
The NDK includes a cross-compiler toolchain for generating ARM binaries that can be deployed in Android APK packages. Google says that native code should be used sparingly and is not appropriate for the vast majority of third-party Android applications. The company also points out that using it could reduce portability and have other negative consequences.
"The NDK will not benefit most applications. As a developer, you will need to balance its benefits against its drawbacks; notably, using native code does not result in an automatic performance increase, but does always increase application complexity," the documentation says. "Typical good candidates for the NDK are self-contained, CPU-intensive operations that don't allocate much memory, such as signal processing, physics simulation, and so on."
In addition to delivering support for native code, Google is also extending Android to support popular dynamic scripting languages. Earlier this month, Google launched the Android Scripting Environment (ASE) which allows third-party developers to build simple Android applications with Python and Lua.
The ASE provides access to platform framework capabilities through a JSON RPC bridge. This means that scripts which run on top of the ASE can actually leverage other capabilities of the operating system, such as controlling the ringer volume, toggling WiFi, making calls, detecting the user's current location, launching activities, and handling intents. One of the most compelling aspects of the ASE is that it allows users to code new scripts on the device itself.
Tuesday, June 23, 2009
Object Relation Mapping and Java Persistence: Data Modeling and Legacy Schemas
These days, it’s essential to have a strong knowledge of object relational mapping. This reflects the need for retaining application data long after the application has run. As the need for data storage grows, so too does the need to work with legacy databases or schemas. A schema is simply a description of a database—i.e., its tables, data types, constraints, etc.
Before working with legacy schemas, it’s sometimes necessary to learn more complex mapping techniques. This knowledge will help you in working around what are often quirky legacy schemas. Very often, it’s simply not an option to modify a legacy schema.
A key concept in object relational mapping is the difference between entity and value types. Let’s now look at this concept.
Entity and Value Types
In Hibernate, types can be either entity or value. An entity type has a persistent identity that can outlive the application that creates it. In other words, an entity is persisted to the database, loaded from the database, updated, etc. A value type, on the other hand, doesn’t have a persistent identity and may be considered no more than a set of attributes that relate to a more important entity. For a developer who’s starting up the object relational mapping value chain, there is a temptation to just lump everything in to the one class definition. Doing so misses an important design opportunity.
In summary, a value type may be a component of an entity. We need to make this more concrete! A typical example of an entity type is a user—e.g., a system user. The postal address of a user is more likely to be a value type. In some ways, you can think of a value type as an attribute of an entity. Let’s now see an example of how to map an entity and value type.
Before working with legacy schemas, it’s sometimes necessary to learn more complex mapping techniques. This knowledge will help you in working around what are often quirky legacy schemas. Very often, it’s simply not an option to modify a legacy schema.
A key concept in object relational mapping is the difference between entity and value types. Let’s now look at this concept.
Entity and Value Types
In Hibernate, types can be either entity or value. An entity type has a persistent identity that can outlive the application that creates it. In other words, an entity is persisted to the database, loaded from the database, updated, etc. A value type, on the other hand, doesn’t have a persistent identity and may be considered no more than a set of attributes that relate to a more important entity. For a developer who’s starting up the object relational mapping value chain, there is a temptation to just lump everything in to the one class definition. Doing so misses an important design opportunity.
In summary, a value type may be a component of an entity. We need to make this more concrete! A typical example of an entity type is a user—e.g., a system user. The postal address of a user is more likely to be a value type. In some ways, you can think of a value type as an attribute of an entity. Let’s now see an example of how to map an entity and value type.
Saturday, March 28, 2009
Is IBM (IBM) Deal To Buy Sun (JAVA) In Trouble?
Inevitably, when a corporate buy-out is announced or rumored, the target company’s stock prices trades up to the level of the value of the deal.
Last week, there was news that IBM (IBM) was likely to buy Sun (JAVA) for about $10 a share. Sun’s stock jumped from under $5 to almost $9 in one day. But, since then Sun’s shares have been moving down. They closed the week at $7.83, well below the rumored purchase price.
There could be several reasons that IBM has either lost interest in Sun or is considering lowering a purchase price. One is that Sun has lost money or broken even in several of its most recent quarters. In the periods when the company did make a profit, it was modest. It may be that IBM has discovered that the next several quarters look weak for Sun.
Alternatively, IBM may have found out the the value of Sun’s customer contracts going forward are not as strong as it may have initially believed. Sun may be losing market share to larger competitors like Hewlett-Packard (HPQ). If Sun’s piece of the server global server industry is dropping rapidly, IBM may be considering walking away from a transaction or lowering its offer.
Whatever the reason, the fact that no deal has been announced is not good news for Sun.
Last week, there was news that IBM (IBM) was likely to buy Sun (JAVA) for about $10 a share. Sun’s stock jumped from under $5 to almost $9 in one day. But, since then Sun’s shares have been moving down. They closed the week at $7.83, well below the rumored purchase price.
There could be several reasons that IBM has either lost interest in Sun or is considering lowering a purchase price. One is that Sun has lost money or broken even in several of its most recent quarters. In the periods when the company did make a profit, it was modest. It may be that IBM has discovered that the next several quarters look weak for Sun.
Alternatively, IBM may have found out the the value of Sun’s customer contracts going forward are not as strong as it may have initially believed. Sun may be losing market share to larger competitors like Hewlett-Packard (HPQ). If Sun’s piece of the server global server industry is dropping rapidly, IBM may be considering walking away from a transaction or lowering its offer.
Whatever the reason, the fact that no deal has been announced is not good news for Sun.
Monday, March 9, 2009
JSR 223: Scripting for the Java Platform
We have all heard heated arguments between developers who use scripting languages and developers who use Java. One of the reasons for the war between these two factions is that the process of integrating the two was so difficult that developers on both sides were almost forced to choose one or the other. Java Specification Request (JSR) 223 addresses this issue. In this article, I present examples of how the standard framework and API defined by JSR 223 makes it easy for Java programmers to take advantage of the benefits of using a scripting language while retaining the benefits of using Java.
The Scripting API
The entire scripting API is contained in the package javax.script, which was first delivered with Java 6. This lightweight package contains six interfaces:
Bindings
Compilable
Invocable
ScriptContext
ScriptEngine
ScriptEngineFactory
five classes:
AbstractScriptEngine
CompiledScript
ScriptEnginemanager
SimpleBindings
SimpleScriptContext <.ul>
and a single exception:
ScriptException
Rather than describing each of these interfaces, classes and exceptions, I present a series of five Java programs and five scripts in three languages to show just how little effort is required to make them work together.
The Scripting API
The entire scripting API is contained in the package javax.script, which was first delivered with Java 6. This lightweight package contains six interfaces:
Bindings
Compilable
Invocable
ScriptContext
ScriptEngine
ScriptEngineFactory
five classes:
AbstractScriptEngine
CompiledScript
ScriptEnginemanager
SimpleBindings
SimpleScriptContext <.ul>
and a single exception:
ScriptException
Rather than describing each of these interfaces, classes and exceptions, I present a series of five Java programs and five scripts in three languages to show just how little effort is required to make them work together.
Subscribe to:
Posts (Atom)
