Siebel TBUI View cannot render Gantt Chart Applets

I was trying to do a Proof of Concept for a project, and it was around Siebel's Task Based UI system. The scenario was for a Service Request manual assignment system, and the user was supposed to assign the SR to an available agent. If you drilldown on the "Status" field of an Activity from the "Service Request Detail View", Siebel will take you to a Gantt Chart View : "FS AxGanttChart View", where the availability of the agent can be seen in a nicely rendered chart.

 

 

 

Then the Activity can be dragged and dropped into the Gantt Chart applet above. I was trying to move this vanilla functionality into the end of a custom TBUI, and I pulled the top applet "FS Dispatch Board Gantt Applet" into the TBUI.

 

Compiled, and tested.

 

 

Bummer !

 

Gantt Chart applets do not get rendered properly in the TBUI. It breaks the layout completely.

 

 

I guess I'll just have to add this to the list of things I hate about Siebel.

 

Window Live Writer no longer connects to Blogger

Today I started seeing errors when I tried to post to blogger via LivWriter

Turns out, the issue is because Google has made  changes to thier APIs and authentication system, that LiveWriter can no longer authenticate in.

The blogger online composer works fine, but uploading images there is a real pain.

Here is another way out..if you want to post to blogger, but do not want to use the online composer...

you can...just mail it in !

In your blogger account, you can turn on a secure email system, and any email you send to this account will be published automatically !

Go down to Settings-> Mobile and email

Set up a new email id and select "Publish email immediately". Any e-mail you send to this id will be published. So be sure NOT to share this email id with anyone.

You can insert images into the e-mail, and they will be handled by blogger correctly the same way it did for livewriter.

This is how I am posting this post as well..

Enjoy !!

JAVA is 20

 

The JAVA programming language grows 20 years old this year.

May 23 marks 20 years since the first version of Java was released for public use. The timing of its arrival coincided with the advent of the web and the new role technology took in improving business productivity, streamlining business processes, and creating new ways for businesses and customers to interact.

The importance of a given programming language—especially one as pervasive as Java—in changing how people use technology is difficult to underestimate. The big data revolution, for example, is primarily a Java phenomenon.

In industry and business, most of server-side computing is done using Java applications. And much of the Internet of Things is also emerging on Java devices.

But 20 years ago, the language was delivered to an entirely different set of needs: a good, general-purpose language for desktop computing.

Java arrived at an important moment in software development. Up until then, the primary programming languages were few and well-established: Fortran in scientific computing, COBOL in business, and C or the emerging C++ everywhere else in commercial programming.

While less popular languages filled specific niches—Ada (defense), Pascal (hobbyists and consultants to SMBs), Smalltalk and Lisp (academia), Perl (system administrators), and so on—the Big Three dominated computing.

Fatigue with C

However, a fatigue with C was definitely emerging. The language had two major handicaps in those days: First, it was too low level—that is, it required too many instructions to perform even simple tasks. Second, it wasn’t portable, meaning that code written in C for the PC could not easily be made to run on minicomputers and mainframes.
The low-level aspects, which still are apparent today, led developers to feel that writing applications in C was akin to mowing the lawn with a pair of scissors. As a result, large software projects were tedious and truly grueling.

The portability of C was also a major problem. Although by 1995, many vendors had adopted the 1989 ISO standard, they all added unique extensions that made porting code to a new platform almost impossible.

It’s no coincidence, then, that this era saw the emergence of a new generation of languages. In 1995 alone, there appeared Ruby, PHP, Java, and JavaScript.

Java almost immediately became popular for mainstream programming due to its portability and large set of built-in libraries. The then-mantra for Java was “write once, run anywhere.” While not strictly true initially, it quickly became so, making Java a good choice for business applications that needed to run on several platforms.

IBM  subsequent embrace of Java (especially via Project San Francisco) clinched the new language’s central place in business programming.

Once a language becomes mainstream, it tends to have a long lifetime, as will be demonstrated this year when the languages born in 1995 all begin celebrating their twentieth  anniversaries. What makes Java stand out, though, is how much the language and platform have evolved in that time span.

Most conspicuous, to me at least, is the change in the Java Virtual Machine (JVM JVM). While it delivered portability almost from the start, it did not initially deliver speed. Java was known for being slow to start and slow to run.

Continual Improvements
Today, Java is among the fastest languages and can scale to programs that can process vast resources, as the big data revolution—a mostly Java-based phenomenon—has amply demonstrated.

The language, too has seen extensive revision. From a start in which there were rough corners lying here and there, Java has evolved into a tool that can address almost every kind of programming problem.

The advent of Java 8 in particular added important features taken from functional programming idioms that make code shorter, more reliable, and more expressive.

The details of Java’s history are so well known that it’s easy to forget how truly rare it really is. The rarity is that few languages have benefited from constant, large-scale engineering investment for two decades. Among major languages today, only Microsoft MSFT C# (and the .NET runtime) has been favored in this same way.

At one time, it was hoped that large communities of developers would be capable of driving this change by themselves. And certainly, the rapid pace at which early development tools advanced gave all programmers reason to believe. But those early tools turned out to be outliers, rather than heralds of coming things.

So, while others might celebrate 20 years of Java as if language endurance were in itself a major accomplishment, I prefer to celebrate the sustained rate of innovation and the 20 years of continuous investment required to make that happen.

 

 

Oracle's Version

 

Other media:

 

The technology community is celebrating 20 years of the Java programming language, heralding its use by some nine million developers and the fact that it runs on seven billion devices worldwide.

The language was launched in 1995 by Sun Microsystems, and is now run as part of Oracle after the firm acquired Sun in 2010.

Georges Saab, vice president of development for the Java Platform Group at Oracle, explained that the Java programme has been one of the most important of the past two decades.

“Java has grown and evolved to become one of the most important and dependable technologies in our industry today,” he said.

“Those who have chosen Java have been rewarded many times over with increases in performance, scalability, reliability, compatibility and functionality.”

As part of the celebrations, Oracle has released a detailed timeline of the history of Java, starting as far back as 1991 and the background to its inception when it was called Oak.

Other technology giants that use Java, such as IBM and Fujitsu, have lined up to sing the praises of the platform, and executives from both firms noted its impact over the past 20 years and looked ahead to its future.

"IBM is celebrating Java's 20th anniversary as one of the most important industry-led programming platforms spanning mobile, client and enterprise software platforms,” said Harish Grama, vice president of middleware products at IBM Systems.

“IBM looks forward to the next 20 years of growth and innovation in the Java ecosystem, including mobile, cloud, analytics and the Internet of Things."  

Yasushi Fujii, vice president of Fujitsu's Application Management Middleware Division, said: “Fujitsu recognised the utility of Java in IT systems as soon as it first became available, and even now we are working to promote its applications.

"We expect that Java’s continuing evolution will lead to further ICT development and a changing society, and look forward to working with the Java community to develop Java technologies."

One company that is perhaps not going to join in the celebrations is Google, which is in the middle of a long-running $1bn patent battle with Oracle over the use of Java in the Android operating system.

Oracle has also faced criticism for its management of Java, specifically that it releases security updates for the software only every quarter, often leading to huge patch releases that can cause headaches for IT admins.

Nevertheless, Oracle said that its stewardship of Java since acquiring Sun has seen two major platform releases, Java 7 and Java 8, as well as the next release, Java 9, slated for 2016.

Java 9 is set to include a new feature called Project Jigsaw which aims to "modularise the platform" to make it scalable to a wider range of devices and easier for developers to build larger applications on the platform.

As part of the celebrations, Oracle is offering a 20 percent discount on all Java certification exams until 31 December.

 

 

 

Reload Original PagePrint PageEmail Page

Java At 20: The JVM, Java's Other Big Legacy

Think of Java, which celebrates its 20th anniversary this week, and your first thoughts most likely go to the language itself. But underneath the language is a piece of technology that has a legacy at least as important and powerful as Java itself: the Java virtual machine, or JVM.

20 years of Java

Because the JVM wasn't designed to run any particular language -- Java is only one of many possibilities -- it's become somewhat of a platform unto itself. Languages have been developed for the JVM that owe little or nothing to Java, and the future development of the JVM is turning more to empower the creation of new items that can leverage Java's existing culture of libraries and software or depart from it entirely.

The engines under the JVM hood

When people talk about the JVM, they're generally referring to a specific JVM: the one originally produced by Sun Microsystems and now owned by Oracle, which uses the HotSpot engine for just-in-time compilation and performance acceleration. With proper warmup time for long-running applications, code operating on HotSpot can sometimes meet or beat the performance of code written in C/C++.

Nothing says the HotSpot-empowered JVM has to be the one and only implementation of Java, but its performance and many years of development have made it the de facto choice for good reason. A galaxy of other JVMs have come (and gone), but HotSpot itself -- now an open source project -- remains the most common option for enterprise production use.

Here and there, though, others are attempting to become the keepers of their own JVM flame: One programmer, for instance, is developing a JVM entirely in Google's Go language -- although right now more as an experiment than as a serious way to give HotSpot any kind of competition.

Because of all the advanced optimization work put into HotSpot, the JVM has over time become a target platform by itself for other languages. Some are entirely new creations designed to exploit the JVM's high speed and cross-platform deployment; others are ports of existing language. Plus, using the JVM means devoting less work to creating a runtime for a language from scratch.

The big JVM stars: Clojure, Scala, and Groovy

Of the languages created anew on the JVM, one stands out for being most unlike Java as possible: Clojure, a functional language designed (in the words of its creator, Rich Hickey) to be a "kind of a Lisp for the JVM," one "useful anywhere Java is." Or even where Java isn't: Puppet Server, for example, recently swapped out Ruby for Clojure as its core language, citing performance as one reason for the switch.

Aside from its power as a functional language, Clojure illustrates one of the fringe benefits of creating a language for the JVM: access to all of the resources provided by Java itself, typically libraries like Swing or JavaFX. To that end, developers more comfortable with Clojure can write programs sporting platform-native UIs, by way of what Java already offers -- but without having to write Java code directly.

Scala, another functional language for the JVM, hews more closely to Java in terms of syntax, but it was created in response to many perceived limitations of Java. Some limitations, like the lack of lambda expressions, have been addressed in recent versions of Java. However, Scala's creators believe suchimprovements will leave developers wanting even more -- and Scala, not Java, will provide them in ways that developers will prefer.

Groovy, formerly stewarded by Pivotal but now an Apache Software Foundation project, was also developed as a complement to Java -- a way to mix in features from languages like Ruby or Python while still keeping the resulting language accessible to Java developers. It, too, functioned in part as a critique of Java by providing less-verbose versions of many Java expressions.

The JVM ports: Jython, JRuby, and the rest

Another side effect of the JVM serving as a language target: Implementations of several languages now run there as well. For example, if you thought Node.js was the first time JavaScript ran as a server-side entity, think again: Mozilla's Rhino has been doing so, in Java and on the JVM, since 1999 (albeit in only an open source variety after 2006).

Most prominent among the ported languages -- and relevant to enterprise developers -- are Python and Ruby, which have been implemented in JVMs as Jython and JRuby, respectively. As with the other JVM languages, hosting Python and Ruby on the JVM gives them access to the existing universe of Java software. This relationship works both ways: You can leverage Python from within Java applications as a scripting language for testing, by way of Jython.

Despite the speed of languages on the JVM, there's no guarantee that a JVM-ported version of a language will be higher-performing than its other incarnations. Jython, for example, is sometimes faster, sometimes slower than the conventional CPython implementation; performance depends greatly on the workload. Likewise, JRuby can be faster than its stock implementation, but not always.

Another disadvantage of a JVM-hosted version of a language: It doesn't always track the most recent version of the language. Jython, for example, supports only the 2.x branch of Python.

The next steps for the JVM

Even apart from performance issues, it's unlikely any of these languages will replace Java. But that has never been the plan -- after all, why replace Java when it's so widely entrenched, successful, and useful?

Instead, it's better to take the culture that's sprung up around Java -- all the libraries and applications -- and make it useful by way of the JVM to far more than Java programmers.

Next, the JVM must become easier to use as a development environment for forward-thinking language work. In 2014, Oracle unveiled Graal VM, a project that exposes the JVM's innards via Java APIs. When completed, this will allow programmers to create new languages for the JVM by using Java as a kind of command-and-control language. (Prototypes of JavaScript, Ruby, and R hosted with Graal showed promising, if inconsistent, results.)

Tougher to predict is whether the JVM or its successors can foster a new language that's as influential and broad as Java itself -- or whether such a language comes from another direction entirely.

JavaScript and the V8 engine for JavaScript are strong candidates as influential successors to Java. Node.js already has a culture of software reuse akin to Java's own, and languages that transpile to JavaScript allow use of the ecosystem without having to write JavaScript.

But with Java preparing for major makeovers, languages on the JVM seems far closer to the beginning of their journey than to the journey's end.

Oracle BI Publisher 11.1.1.9.0 is available !!!

 

 

Oracle BI Publisher 11.1.1.9.0 was GA on May 19th and you can get the download, documentation, certification matrix and release notes here at the BI Publisher home page in OTN. Here is a quick snapshot of new features in this release. The download is also available at Oracle Software Delivery Cloud site. The documentation page has also been given a fresh new structure.

Well, the Word Addon is still not updated, which means it still does not support Microsoft Word 2013. But templates can be created online on the BIP server site itself.

TCC: Prevent Duplicates in Exports

 

 

Sometimes while running TCC exports with some complex filters, the same record might turn up more than once in in the final export file. The reason for this is that Taleo has a fixed datamodel, the relationships between various entities is pre-configured and cannot be overriden. So and M:M relationship cannot be converted to 1:M. Due to this, some records might be exported multiple ones.

Turns out, there is an easy way to fix this in the export process itself In the General tab of the Export file setup ,click on Advanced.

 

 

On the popup window, check the "Prevent Duplicates" option. This will ensure that records get exported only once in an export file.

Stop Using Tail -F (Mostly)

 

I still see a lot of people using tail -f to monitor files that are changing, mostly log files. If you are one of them, let me show you a better alternative: less +F

The less documentation explains well what this +F is all about:

Scroll forward, and keep trying to read when the end of file is reached. Normally this command would be used when already at the end of the file. It is a way to monitor the tail of a file which is growing while it is being viewed. (The behavior is similar to the "tail -f" command.)

So it says that it's similar to tail -f, but why I think it's better?

Simply put, it allows you to switch between navigation and watching mode. We all have been there: You are watching a file with tail -f, and then you need to search for something in this file, or just navigate up and down. Now you need to exit tail (or open a new shell), and ack this file or open it with vim to find what you are looking for. After that, you run tail again to continue watching the file. There's no need to do that when you are using less.

Let's say you want to watch the file production.log:

$ less +F production.log

Important
log
information
here

Waiting for data... (interrupt to abort)

Here you have pretty much the same behaviour you'd get with tail.

Now let's say something interesting appears, and you want to search all the occurrences of "foo". You can just hit Ctrl-c to go to "normal" less mode (as if you had opened the file without the +F flag), and then you have all the normal less features you'd expect, including the search with /foo. You can go to the next or previous occurrence with n or N, up and down with j and k, create marks with m and do all sort of things that less(1) says you can do.

Once you are done, just hit F to go back to watching mode again. It's that easy.

When you need to watch multiple files at the same time, tail -f can actually give you a better output. It will show you something like this:

$ tail -f *.txt

==> file1.txt <==
content for first file

==> file2.txt <==
content for second file

==> file3.txt <==
content for third file

When a change happens, it prints the file name and the new content, which is quite handy.

With less, it would be like this:

$ less +F *.txt

content for first file

It shows the content of just one file at a time. If you want to see what's happening in the second file, you need to first Ctrl-c to go to normal mode, then type :n to go to the next buffer, and then F again to go back to the watching mode.

Depending on your needs, it might still be worth to use less for multiple files, but most of the time I just go with tail for these cases. The important thing is to know the tools that we have available and use the right one for the job at hand.

The Failure Of Agile

 

I have always felt that Agile has failed. No Indian IT company I know of implements agile in its truest form. So it was not surprising to see one of the creators of agile himself ranting about this. He is also proposing a new standard.

Enjoy.

TCC: Transition Attachments need to be unzipped twice

 

TCC (Taleo Connect Client) is Taleo's (Enterprise Edition) official data export/import tool, but it does not allow manipulations on files uploaded/attached into the Taleo system.  To work with files attached, you need the TCC Custom Steps library. But again, it appears though stores files uploaded into some modules differently on their system.

For documents in the Recruiting module, Taleo first compresses, and then encodes the file in Base64. This is because internally it uses webservices for TCC, and Base64 seems like the only way to send binary attachments over SOAP XMLs. So while using TCC Custom Steps to export the attached files, you have to first decode the Base64 content, and then unzip it. Fortunately, the library's com.taleo.integration.client.customstep.xml.ExtractAttachedFilePostStep class does this automatically.

But when I used the same step to export documents from the Transitions module, the final files appeared corrupted, they would not open up in file viewers for PDF or Doc format. Turns out, the files exported are still in zip format. They need to be unzipped once more to get the final file.

So for Transition module, Taleo Zips it twice, then Base64 encodes it once. For exporting the files using TCC, the need to be unzipped twice. The above mentioned class does not do this automatically.

Answer: Different Class

The Custom Library documentation mentions another class in the same library ,com.taleo.integration.client.customstep.xml.ExtractFilesPostStep , which has more options.

 

According to the documentation, for documents, this step needs to have an operation value of "DecodeBase64,Gunzip". It does not mention whether operations can be chained.

They can. For transition documents, the operation has to be "DecodeBase64,Gunzip,Gunzip"

Here is the final configuration:

The final files generated by this sequence perfectly opened up in a PDF reader, so all transition forms are stored in PDF format in Taleo.