How do I… Create a customized JavaScript jump menu in Dreamweaver CS3?

If you are in charge of maintaining a Web site, one of your recurring tasks is likely accommodating a committee of supervisors or clients that want to add links to the site on a continuing basis. This can often lead to a cluttered navigation interface, if it doesn’t destroy your layout altogether.

Fortunately, Adobe Dreamweaver CS3 has many tools that can provide quick and easy solutions to problems like these. One of the more practical solutions to an ever-expanding list of navigation links is a JavaScript “jump” menu, which is a pull-down form menu that automatically directs the user’s browser to another Web page as soon as they select an option from the menu. And the best part is that no knowledge of advanced scripting techniques is required to implement it. You can even use some simple CSS code to give your Jump menu a distinct look.

If you don’t own a copy of Dreamweaver CS3, you can download a fully functioning 30-day trial.

This blog post is also available as a TechRepublic gallery and TechRepublic download. The download includes an example of the JavaScript described in this How do I… blog post.

Let’s begin by opening Dreamweaver and creating a new HTML document (Figure A) by selecting the New option from the File menu. In the Dialog box that appears, Select HTML in the Page type column. Ignore the other options in the box, and click the “Create” button.

Figure A

Creating a new HTML document in Dreamweaver CS3

Before you do anything else, save your document. It is always a good idea to save a new HTML document in Dreamweaver in the directory that houses your parent Web site before you begin coding. This will help avoid broken and misdirected links later on if you decide to link to internal site pages.

Dreamweaver lets your author a page via its WYSIWYG tools as well as by hand-coding. Its best to have both options visible at all times so that you can switch back and forth and see how modifying the code affects the browser preview and vice-versa. If both the Code and Design view are not visible, click on the button that is labeled “Split”. You will find it in-between the Code and Design buttons near the top of the screen, under the document tab (Figure B).

Figure B

Clicking the Split button lets you see both the Code and Design windows

Now it is time to build our Jump menu. Go to the top of the screen and in the horizontal Insert menu (it runs across the screen just under the Application menus) click on the Forms tab to bring up the Form objects. (Figure C)

Figure C

Select the Forms tab to bring up the Form objects palette

Next, click on the Jump Menu button. This will make a dialog box appear, as in Figure D.

Figure D

Click the Jump Menu button to bring up the Jump Menu authoring box

Let’s have the first item in our Jump Menu take us to Google.com. The field labeled “Text:” is the text that will appear in the menu when the user views it in his browser. It can be whatever you wish, including most special characters. For now, let’s keep this simple. In the “Text;” field, enter the word Google (Figure E). The field below it, labeled “When selected, go to URL:” is the Web address that will be the destination tied to the copy in the “Text:” field. Enter the URL http://www.google.com.

Figure E

Creating the first item in the Jump Menu

Next, let’s add two more items to the Jump menu. Click the Add Item button two times and you’ll see the Jump menu add two more blank entries. (Figure F)

Figure F

Adding two blank items to the Jump Menu

Click on item1 in the Menu Items list and fill out the Text and Selected URL fields just as you did before, linking the new item to an absolute URL. Repeat the process again with item2. (Figure G)

Figure G

Linking the two new menu items

Now let’s say that you want to rearrange the order of the items in the menu list. This is easily done with the two arrow buttons in the upper right area of the dialog box. Click on the last entry in the Menu items box to select it. Then click on the up arrow until the last item is now at the top of the list, as in Figure H.

Figure H

Re-ordering the Menu items

When you are satisfied with the content of your Jump Menu, click the OK button to return to Dreamweaver’s main authoring area to see your menu. (Figure I)

Figure I

The newly-created Jump Menu

Before we test it, let’s use some simple CSS code to make the Jump Menu a little more distinguished. Go to the top of the screen and from the Window menu, select the CSS option. The CSS palette will open, as shown in Figure J.

Figure J

The CSS palette

Click on the Add CSS Rule button to bring up the CSS Rule dialog box (Figure K). In the Selector Type options, choose the Tag option. In the Tag pull-down menu, choose the “Select” tag. Finally, click the Radio button at the bottom that is labeled “This document only.”

What these options do is define the appearance of your Jump Menu automatically, so that you do not have to assign a CSS class to the menu later or worry about an external Style sheet. Click OK to continue to the CSS Rule Definition dialog box.

Figure K

The New CSS Rule dialog box

The CSS Rule Definition dialog box will open at the Type Category, From the Font pull-down menu, select the font set “Arial, Helvetica, sans-serif”, then give it a size of 10, as shown in Figure L.

Figure L

Defining Type options for the New CSS Rule

Now select the Background Category and select a light value color, as shown in Figure M.

Figure M

Defining Background options for the New CSS Rule

Click OK to return to Dreamweaver’s authoring area. The styles you defined should be readily viewable in the Jump Menu. (Figure N) Save your document, and then open it up in a Web browser to test it.

Figure N

The completed Jump Menu

There is no limit to the number of items the Jump menu can list, and of course, you can even link it to Web pages within your own Web site. Use the CSS customization to make it fit right in with your site’s unique look and feel.

courtesy @Techrepublic

fetched from blog4aurobindo(blogspot)

Stop the systematic abuse of object-oriented programming

Object-oriented programming (OOP) has become the dominant type of programming over the last 10 years or so; a major driver of this has been Java, VB.NET, and C#. But what I keep seeing more and more is that too many programmers using object-oriented languages really do not understand OOP.

A huge misunderstanding is the concept of encapsulation. Encapsulation is meant to hide the underlying implementation of a concept from the code that makes use of the object — not to expose it. The idea is that the consuming code does not need to know or care about the particular implementation “under the hood,” so it can be changed without affecting anything else. Encapsulation works hand-in-hand with polymorphism.

Between encapsulation and polymorphism, code can (and should) be extremely loosely coupled. But really it isn’t in many pieces of code that I have seen. Far too many objects end up simply being equivalent to a Pascal “type” structure, a strongly typed collection of other types, gathered in one spot for easy reference. Another fairly common misuse of OOP is to write “classes” that play out like hashtables of hashtables of hashtables. While that type of programming made sense in Perl for a variety of reasons (not the least of which is the lack of a comprehensible object system in Perl), it is not in the spirit of OOP.

Why are these techniques a problem? For one thing, they require too much knowledge by the consumer of the underlying functionality. The first example leads to these statements that look like this:

FooObject.Property.Item(Index).Method(Parameter 1, Parameter2).Property = BarObject.Method(Parameter 1).Property.ToKludgeObjectType()

If the consumer has no idea what any of those sub-properties, methods, and so on do, they cannot get too far using either of these classes. On top of that, by exposing so many of the internals to the consumer in what will need to be a full-access manner, the encapsulating object hands over full control. This can cause some real damage, particularly if those contained classes have properties or methods with negative consequences.

The second type that I describe typically looks something like this:

FooObject("Property").Item(Index).Method(Parameter 1, Parameter 2)("Property") = CType(BarObject.Method(Parameter 1).Item("Property"), KludgeObjectType)

Wow… what an utter disaster. Can you imagine working with this? The worst part is that, with all of those collection lookups, you can throw compile time checking out of the window. The person who writes this manages to combine a very dangerous aspect of dynamic languages (lack of compile time checking) with the worst of compiled languages (design time knowledge of types) into something that derives none of the benefits of either type of language. One “fat finger mistake” in all of those lookup values will compile just fine, but come run time, they will become errors of one sort or another. It would not be so bad if a simple mistake just lead to an outright exception like “Index out of range,” but if the mistake just happens to be purely logical (e.g., the item named does exist, but the wrong item was named), there is a solid chance that the code will keep running but with silent and hard-to-detect corruption of data and/or logic.

I know part of the problem here is simple laziness. I am guilty of it plenty of times. For me, what usually happens is that I am using an OO language for something that I really just need a procedural or mostly procedural language for. Let’s face it, not every application requires too much OO design — they really just need a way of quickly passing a bunch of loosely related data around. But these “shuttle classes” always seem to take on a life of their own, and the next thing you know, you are writing static/shared classes with static/shared members to process the data within the “shuttle classes.” Why? Because you really meant to be using Perl, Pascal, or maybe even Smalltalk or a simple shell script, not C++, Java, C#, or VB.NET (at least for this one part of the project, that is).

Folks, this is where the rubber stops meeting the road. Those earliest experiences with programming will always color our current thought process regarding programming. And nearly universally, we were introduced to programming with a procedural language or a very procedural use of a non-procedural language. Add to that the fact that contrary to popular belief, Java, VB.NET, and C# are not purely noun-oriented OO. After all, they have some primitive verbs in there. What we really just want to do sometimes is to extend the language itself (add new primitive verbs) –that is where those anti-OO static classes of static methods come from, and it is the only way we can really add a new verb to the language. Those pseudo-procedural-functions end up needing a ton of parameters passed to them (just like procedural code), since the data that they are working on is no longer included in the class that they are members of.

At the end of the day, this type of programming is indicative of one or more of the following things:

• The programmer was “born and bred” in a non-OO environment and is untrained in proper OO.
• The programmer does not feel like using the proper OO techniques for whatever reasons.
• The language being used is the wrong language for the job.

I think the last item is a lot more common than most of us care to admit. After all, we turned to OO to save us a lot of headaches, increase code reuse, etc. But none of the OO promises can be fulfilled when we treat an OO language like it is something that it is not. And if we are going to program away the benefits of OO, why bother using the languages?

I guess this is yet another reason why I am fairly pro on the .NET CLR (and would be on the JVM if Sun was more supportive of other languages). It is possible (in theory) to write the right code in the right languages. Sadly, the only two languages with massive support in .NET right now are the nearly identical twins, VB.NET and C#. It looks like the first language to get formal “kid brother” status is the functional language F#. IronRuby and IronPython are still “CodePlex cousins,” in which Microsoft might donate some time, server space, and documentation but little real support. Ruby is also attractive to me because it seems to blend procedural and OO code pretty well. I really, really need to try Ruby out.

The takeaway here is that you really need to get off the couch, learn proper OO, and use it correctly. Otherwise, you are hurting your own efficiency, writing slow code (all of those collection lookups and OO tree traversals are rather expensive!), and making your code difficult to maintain. If you still cannot figure out how to write what you need in an OO-friendly manner, you may need to think about switching languages.

courtesy @TechRepublic

fetched from blog4aurobindo(blogspot)

Developer efficiency myths and truths

If you read the ads in development-related magazines or on Web sites, you would think that solving development inefficiency is a great path to making big bucks — and I believe that it is. There are tons of products on the market that claim to improve developer efficiency, from different languages to IDEs, automated build tools to automated build environments. I will try to bust some myths, bring to light a few truths, and show some partial truths regarding developer efficiency.

Myths about what leads to developer efficiency

#1: Drag ‘n Drop IDEs are the be-all and end-all.

Drag ‘n Drop IDEs are great… for building UIs. Outside of using a Drag ‘n Drop IDE as a graphical code generator for UI-specific tasks, they universally stink. Unless you are writing an application so basic that the IDE’s assumptions about how code should be written won’t hurt things, chances are you will rip out at least half of the code that the Drag ‘n Drop IDE put there for you. Go ahead, use Visual Studio or Eclipse — they are great IDEs. But be wary of trying to drag ‘n drop your way to a complete application.

#2: Slumber parties at the office equal more quality work completed.

I call a workaholic programmer who regularly pulls all-nighters The Martyr. It is tempting to think that putting in more hours equals more work, but most developers are spun out by 5:00 PM. Development is brain-taxing work, and you cannot do it when you’re tired or improperly nourished. A late night here and there may pay off, but chances are, the quality of the work done past 6:00 PM or 7:00 PM is low, and the next day your efficiency will be in the toilet. Avoid the late night work whenever possible — you are not nearly as efficient as you’d like to think.

#3: Caffeine, nicotine, and sugar are your friends.

Caffeine, cigarettes, and sugary beverages contain chemicals that might provide a temporary boost in awareness, alertness, and concentration. But the 30-minute jolt that a can of Mountain Dew might give you is followed by a much longer crash that dulls your senses and fatigues your body. This is why you see people with trash cans full of soda bottles, cigarette packs, and coffee cups; they need to continually ingest the chemical(s) of their choice to find a balance. Trust me, I have been there myself (regrettably, I started drinking coffee again a month ago, but I am still cigarette and sugar free). Try to replace the coffee with water, the sugar with fruit, and find a way to quit smoking. Not only will you stop feeling the nasty side effects of coming down, but you will also have much fewer interruptions when you do not need to leave your desk constantly.

Truths about what leads to developer efficiency

#1: Environment matters

No, I am not talking about Al Gore or Greenpeace. If you are in an office, I bet good money that there is a standard fluorescent light bulb over your head. It probably cost the builder $45 or less to install; meanwhile, full-spectrum task lights can easily cost over $100.

Ever notice how many IT pros turn the lights out in the office? It is because fluorescent lights are horrible on your eyes when you’re using a PC; turning the lights off reduces the immediate stress on your eyes that causes the 2:00 PM headache. The problem is that your eyes dilate even more when you turn the lights off, letting even more of the eyeball killing monitor light damage them. In other words, the short term “fix” does long term damage. Go ahead, buy the $100 task lamp; it is cheaper than a new pair of glasses or contacts, and it will improve your efficiency significantly since you won’t be in pain by mid-afternoon.

#2: Practice makes perfect

A lot of developers think that warming a chair for 10 years makes them a better programmer. The fact is that someone who spends time reading about new ideas and trying them out on their own time is going to learn valuable lessons that they can apply in their day-to-day work. If you want to become more efficient, I suggest spending time working on a project (at home or set aside an hour or two a week at the office) that is related to work but that uses techniques that are new to you. You will discover that learning new techniques always pays a huge dividend.

#3: Limit interruptions

Your manager is making you less efficient. Every time he or she stops at your desk for a quick status update or e-mails you a memo reminding the team of the dress code policy, your concentration is broken. Even a slight distraction of a minute or two can take many more minutes to recover from and get back in “the zone.” Add that up over the course of a day, and you could be losing up to an hour’s worth of time where you are fully “in the problem” due to your manager or a coworker interrupting your thought process.

Close the door (if you have one), put blinders on so people near you don’t bother you, and close your e-mail and IM clients. Limit opening your communications software to a few times a day (after a meal, a restroom break, or other similar time is perfect, since you have already lost your train of thought anyway). If it is really important, they can pick up the phone and call you.

Partial truths about what leads to developer efficiency

#1: Code generators may lead to more work on your end.

If you are doing a ton of rote tasks, like creating the accessors for a class that represents a 200 element XML schema, code generators are great. Drag ‘n Drop IDEs make short work of generating UI code, but unless your task is extremely generic, you will probably spend more time tweaking the generated code than it would have taken you to just write it yourself. For specialized tasks, sometimes a text editor that supports regex find/replace or a spreadsheet program like Excel can do a task in a few moments where pricey code generators fall flat.

#2: Language matters some of the time.

Sometimes language matters, and sometimes it doesn’t — it is completely situational. For example, many of the languages that can be written extremely quickly thanks to type inference or syntactic tricks are often difficult to follow when they are maintained. The two minutes worth of typing saved can cause an hour of wasted time down the road. The current mainstream languages (Java, VB.NET, and C#) are all so similar (VB.NET is slightly more verbose) that none of them are particularly more efficient to work with. Some languages do have unique properties and advantages that can significantly impact development time. For instance, try writing something that is as pure logic (or math) as a weather forecasting system in C#, and you’ll be sorry. On the flip side, a typical Windows desktop application written in Fortran will probably take forever. Library support matters too; some languages, despite being weaker, in and of themselves, have library support that makes up for it.

#3: Personal life

Developers who get phone calls from friends and family for a total of two hours a day are probably not going to get much done. However, locking people down is not going to fix the issue of personal calls either. For many people (particularly those with children), a five minute phone call might save a trip home. In an ideal world, developers would not let their personal life and issues affect their work. In the real world, an argument with a spouse, money worries, the kids’ grades, and so on can and will spillover into someone’s work time.

So, for all you managers out there, while personal telephone calls represent an obvious inefficiency, it’s fairly useless to have a programmer in the office who has something heavy on his or her mind. They won’t be able to concentrate anyway, so go ahead and let them do what they need to do within reason.

Are you a developer??? cheers Aurobindo

fetched from blog4aurobindo(blogspot)

Support rich text with the Yahoo User Interface Library

During a recent project, my team’s task was to redesign a Web page that utilized an ActiveX control as a rich text editor. One goal of the project was to replace the ActiveX control with a more standardized approach. We chose to use the rich text editor available with the Yahoo! User Interface (YUI) Library. This week I examine using the YUI Library’s Rich Text Editor.

YUI! Library

The YUI Library is a set of utilities and controls in JavaScript, as well as CSS templates for building richly interactive Web applications using standard technologies such as DHTML, DOM scripting, and AJAX.

You can download the YUI Library 2.3.1 for free from SourceForge.net. The download allows you to install the libraries on a Web server. Another option is to use the library files directly from Yahoo! servers. Yahoo! provides an excellent overview of how to use its servers for applications implementing functionality via the YUI Library.

Rich Text Editor

A recent addition to the YUI Library is the Rich Text Editor. It is a user interface control that replaces the standard HTML textarea element. It allows for the rich formatting of text content, including common structural treatments like lists, formatting treatments like bold and italic text, and drag-and-drop inclusion and sizing of images.

A critical feature of the Rich Text Editor is its toolbar, which provides access to various features like text formatting, color choices, and so forth. You may choose which toolbar features to include in an implementation via scripting. In addition, the toolbar is extensible via a plug-in architecture so that advanced implementations can achieve a high degree of customization.

Putting the Rich Text Editor to work

If you want to use the Rich Text Editor, it requires a YUI Library CSS skin to properly render the control. The following YUI Library files (CSS and JavaScript source files) are necessary to use the Rich Text Editor. The following lines reference the files on the previously mentioned Yahoo! servers, but you may use a local installation as well.

The following base HTML is used to deliver the Rich Text Box, but you’ll still need to add scripting to fully implement the control.

This text will be displayed in the text area.

Now the cols and rows attributes of the HTML texarea element will be overridden by settings specified in the Rich Text Editor’s script. The name assigned to the HTML textarea element is important, since it will be used in the JavaScript code when establishing the relationship between a textarea element and a Rich Text Editor.

Also, the class assigned to the HTML body element (yui-skin-sam) is used to visually format the Rich Text Editor control. This CSS skin is defined in the CSS file imported into the application (see previous list). The skin should be applied to the parent HTML element of the textarea element. In this case, the HTML body element is used, but it could be any element that contains the textarea.

Once the textarea has been defined along with the proper YUI Library files included in the page, the Rich Text Editor control must be rendered. The rendering is accomplished via JavaScript placed within the page. The script can be used to define various Rich Text Editor options such as the toolbar. As an example, I may use the following JavaScript to format our Rich Text Editor:

var rtf = new YAHOO.widget.Editor(‘texteditor’, {

height: ‘300px’,

width: ‘522px’});

rtf.render();

This snippet establishes the height and width of the editor while declaring an instance of the Rich Text Editor. Also, it assigns the textarea called textedtior to the Rich Text Editor. The final line in the script actually causes the Rich Text Editor to display when it calls its render method.

When you use the Rich Text Editor control without any specifics about the toolbar, it results in the default behavior of including all toolbar features like text alignment, font face, font size, color, and so forth. You may choose to limit the toolbar options available to users.

The final example uss a Rich Text Editor, but the toolbar options are defined in the JavaScript code to render it. The following options are used:

• The toolbar options are defined in its own variable. This is later used to instantiate the editor.
• A title is assigned to the editor via the toolbar’s titlebar property.
• The collapse property signals whether the user may collapse/hide the toolbar.
• The buttons property allows you to define the buttons displayed in the toolbar. In this example, buttons are displayed for text formatting as well as selecting colors.

Once the toolbar options are defined, a Rich Text Editor object is instantiated with the toolbar variable passed to it along with the HTML textarea element. The final step is to render the control. A complete list of options is available in the YUI Library API documentation.

Working with YUI Library Rich Text Editor

body { margin:0; padding:0; font-face: arial; font-size: 10pt;}

.yui-editor-container {z-index: 999;}

.editable {

border: 5px solid black;

argin-top: 100px;

margin: .25em;

float: left;

width: 350px;

height: 100px;

overflow: auto;

}

.textbox {

margin-left: 10px;

width: 100px;

height: 25px;

}

.label {

margin-left: 10px;

width: 50px;

height: 25px;

font-weight: bold;

}

First Name:

Last Name:

Test within TextArea.

var toolbar = {

height: ‘200px’,

width: ‘420px’,

toolbar: {

titlebar: ‘TechRepublic.com Editor’,

collapse: true,

buttons: [

{ group: 'textstyle', label: 'Font Style',

buttons: [

{ type: 'push', label: 'Bold', value: 'bold' },

{ type: 'push', label: 'Italic', value: 'italic' },

{ type: 'push', label: 'Underline', value: 'underline' },

{ type: 'separator' },

{ type: 'select', label: 'Arial', value: 'fontname', disabled: true,

menu: [

{ text: 'Arial', checked: true },

{ text: 'Arial Black' },

{ text: 'Comic Sans MS' },

{ text: 'Courier New' },

{ text: 'Lucida Console' },

{ text: 'Tahoma' },

{ text: 'Times New Roman' },

{ text: 'Trebuchet MS' },

{ text: 'Verdana' }

] },

{ type: ’spin’, label: ‘13′, value: ‘fontsize’, range: [ 9, 75 ], disabled: true },

{ type: ’separator’ },

{ type: ‘color’, label: ‘Font Color’, value: ‘forecolor’, disabled: true },

{ type: ‘color’, label: ‘Background Color’, value: ‘backcolor’, disabled: true }

] } ] } };

myEditor = new YAHOO.widget.Editor(‘texteditor’, toolbar);

myEditor.render();

It is worth noting that the text is formatted using standard HTML to format the text within the Rich Text Editor, so bold text uses the HTML strong element; the font element is used for font styling, and so forth.

An improved interface

I have been a big fan of the YUI Library since I first discovered it more than a year ago. It allows developers to build powerful Web interfaces using code that has been fully tested for proper functionality. The Rich Text Editor is just one example of the power controls available in the YUI Library.

courtesy @TechRepublic

fetched from blog4aurobindo(blogspot)

Meeting the software development challenge with static source code analysis

This white paper highlights key business and technology issues facing large software development teams and discusses how Coverity’s groundbreaking static source code analysis technology enables them to detect and fix critical defects and security vulnerabilities early in the development process.

here is the pdf.

source @TechRepublic

fetched from blog4aurobindo(blogspot)

Use Ruby on Rails to create a social networking Web site with full community searching and browsing functionality

Ruby on Rails is fast displacing PHP, ASP, and J2EE as programmers’ development framework of choice, thanks to its elegant design and emphasis on practical results. Learn how to build large-scale projects with Rails by developing a real-world application: a social networking Web site like MySpace, Facebook, or Friendster. In this chapter download from RailsSpace: Building a Social Networking Website with Ruby on Rails, focus on adding searching and browsing functionality to your site. First, add full-text search to your site using the open-source tool Ferret. Then, stalker-enable your site by adding the ability to browse by age, sex, and location.

Title: RailsSpace: Building a Social Networking Website with Ruby on Rails
Author: Michael Hartl, Aurelius Prochazka
Publisher: Addison Wesley Professional
Chapter 11: Searching and Browsing
ISBN: 0-321-48079-1; Copyright 2008 Addison Wesley Professional. All rights reserved.
Used with permission from the publisher. Available from booksellers or direct from Addison Wesley Professional

here is a sample version of Chapter 11 of this book.

source @TechRepublic

fetched from blog4aurobindo(blogspot)

Why developers should check out ColdFusion 8

Adobe ColdFusion 8 (CF is a force to be reckoned with in the application server space. I’ve been using ColdFusion for 10 years, and I haven’t seen the community this excited about a new release in a long time. The recent release is by far the most compelling version since they moved to the Java platform — and possibly even the most compelling version ever.

There is a long list of new features and enhancements in CF 8, but in this article, I’m just going to focus on five of my favorites.

Server Monitor

The Developer and Enterprise Editions of CF 8 offer the highly anticipated Server Monitor feature. This might be the single biggest addition to ColdFusion, since it blows away anything I’ve seen on any other server platform.

Using the beautiful Flex-based Server Monitor interface, you can now watch requests move through a live server. You can see exactly how much memory a session or an application is using, what the template cache is doing, and which threads are taking too long to run.

You can also drill down into live requests and see which individual tags or method calls are slowing things down. It’s immensely powerful to watch the monitor and immediately tune your code in response. Is a query getting executed a lot? Cache it! Is a tag or function causing a bottleneck? Now you know exactly what line of code to optimize. Want to write your own code that runs in response to a hung thread, low JVM memory, or anything else? The monitor API will let you.

Exchange integration

It’s incredibly easy to integrate CF 8 with Microsoft Exchange. With a few lines of code, you can add events to Exchange calendars; add and remove attendees; manipulate tasks, contacts, lists, and more.

Love it or hate it, Exchange is such a staple for many IT departments that the ability to interact with it — or even build your own full-blown interface to your Exchange data — is a big boon to a lot of businesses that use ColdFusion.

AJAX capabilities

Another hugely popular addition in CF 8 is a large set of built-in AJAX functionality. By using simple tags or JavaScript functions, ColdFusion will handle all the chores for creating great AJAX-based applications. CF 8 makes these things a snap: autosuggest, related select boxes, dynamic content updates, and EXT-based datagrids.

One of the coolest features is the ability to create JavaScript proxies for server-side ColdFusion Components (CFCs). You can call a method on the proxy, and under the hood it will make a call to the corresponding method on the CFC. All the work of translating data to and from JavaScript Object Notation, converting ColdFusion datatypes into JavaScript types, and protecting against hack attempts is all handled for you by the ColdFusion server.

There’s even an excellent AJAX debugging window that shows everything that is going on. This probably has the biggest “wow” factor for the new release, since developers of any skill level can whip up a jaw-dropping AJAX application in minutes.

Image manipulation

CF 8 takes image manipulation to a new level. Adobe added more than 50 new tags and functions for dealing with images. The capabilities include simple things like resizing, getting image sizes, and converting images, as well as virtually any image-based task you can imagine. This includes drawing, adding text, and adding effects such as blurring, antialiasing, and rotating.

Performance

The best improvement in CF 8 is that it’s really fast. The development team really outdid themselves in this area. Depending on the application, it can be up to 10 times faster than CF 6 or CF 7. Some processes, like CFC instantiation, are an eye-popping 23 times faster than CF 7. So even if you upgrade to CF 8 and don’t use any new features, your application could easily triple or quadruple its performance on the same hardware. This is quite a compelling reason to upgrade.

Great extras

I’m only scratching the surface of all the amazing new capabilities in CF 8. The list goes on and on to include: generating ATOM and RSS feeds with one line of code; zip file manipulation; built-in Flex Data Services; ColdFusion administrator enhancements; and PDF and PDF form generation. There are three additional benefits to using CF 8 that I will briefly cover.

CF 8 lets you integrate with .NET objects as easily as you can currently integrate with Java objects. The .NET assets can be remote, which means you can use them even if your ColdFusion server is running a UNIX-based OS.

Adobe supplies a series of nice plug-ins for the Eclipse IDE that work with CF 8. This includes simple things like built-in ColdFusion docs, automatic generation of CFCs (including ActiveRecord, Data Access Objects, Beans, etc.), and wizards that will generate a full-blown AJAX application. It also includes a full debugging perspective. In conjunction with the free CFEclipse plug-in, this makes Eclipse the standard IDE for most advanced ColdFusion developers.

CF 8 gives you the ability to do your own thread-based programming. If you have a long running task, you can fire off another processing thread and forget about it; or you can trigger multiple threads to speed up a process and then join them back together and continue.

Download a free edition of CF 8

CF 8 Developer Edition is free, so I urge you to give it an honest look. I believe existing ColdFusion users will find a lot to like in version 8, and new users should try out this application server.

What do you think of CF 8?

Now that I’ve shared my thoughts about my favorite features and enhancements in CF 8, I want to hear what you think of this release. What features do you like the most in CF 8? If you aren’t using CF 8, what features pique your interest enough to give it a look?

fetched from blog4aurobindo(blogspot)

10 signs that you aren’t cut out to be a developer

Programmers make big bucks. Software developers dress casual every day of the week. Anyone can teach themselves to be a programmer. These are just a few of the reasons why people say they want to become a developer. Unfortunately, the job market is littered with people who may have had the raw intelligence or maybe even the knowledge, but not the right attitude or personality to become a good programmer. Here are a few things to consider when deciding whether you should become a software developer.

#1: You’d rather be trained than self-teach

In most development shops, there is rarely any training, even if the company has a training program in place for other employees. At best, the company might reimburse you for a book you buy. Programmers are expected to arrive on their first day with all (or at least most ) of the skills they need. Even worse, the assumption is that programmers are really smart people who are good at problem solving. That assumption leads upper management to believe that good programmers do not need training. Finally, training for developers is extremely expensive. The result? When you change positions, you will need to figure out what is going on yourself, and you will probably need to teach yourself.

#2: You like regular working hours

Software development projects are notorious for being late. Even the projects that are delivered on time always seem to run behind schedule at some point. If you don’t like (or can’t handle) irregular or fluctuating demands on your time by your employer, development is not for you. When crunch time comes, your employer is more concerned with getting the product in the hands of a million-dollar client than with your child’s soccer game or the new TV program you wanted to watch.

#3: You prefer regular raises to job-hopping

The world of development is one of continual erosion of skill value. Unless you are working at a shop that deals with slow-to-change technologies, chances are, your skill set is less valuable every day. The state of the art is changing rapidly, and the skills that are hot today will be ho-hum tomorrow. As a result, it is difficult to sit at the same desk doing the same work every day and expect a raise that exceeds a cost of living increase. You need to keep your skills up to date just to maintain your current value. In addition, if you want to boost your paycheck, you need to expand your skill set significantly and either earn an internal promotion or go to another company.

#4: You do not get along well with others

It’s one thing to be an introverted person or to prefer to work by yourself. It’s another thing to be unable to get along with others, and it can sink you as a developer. Not only that, your manager may well be a nontechnical person (or a technical person who has not worked hands-on in some time), so you need to be able to express yourself to nontechnical people.

#5: You are easily frustrated

Software development is often quite frustrating. Documentation is outdated or wrong, the previous programmer wrote unreadable code, the boss has rules to follow that make no sense… the list is endless. At the end of the day, no one wants to be working next to someone who is always cursing under his or her breath or screaming at the monitor. If you are the kind of person who goes insane spending eight hours to do what appears to be 10 minutes’ worth of work, this is not a career for you.

#6: You are close-minded to others’ ideas

In programming, there are often problems that have only more than one “right” answer. [Update: Corrected by author] If you do not handle criticism well, or do not care to hear the suggestions of others, you might miss something important. For example, a few weeks ago, one of our junior-level people made a suggestion to me. After considering it for a bit, I decided to try it. It turned out that he was right and I was wrong, and his suggestion brought the time to execute a piece of code from multiple days to a few hours. Ignoring this person due to the difference in our experience levels would have been foolish.

#7: You are not a “details person”

Programming is all about the details. If you get lost in a movie more complex than Conan the Barbarian or have a hard time filling out a rebate voucher, you probably won’t do very well in the development world. Sometimes, something as simple as a missing period can mean the difference between random failure and perfect success. If you are the type of person who might not figure out where the missing period is, your career will be limited in range, at best.

#8: You do not take personal pride in your work

Sure, it’s possible to program by the book and do a passable job. The problem is, the book keeps getting rewritten. Software development is not a factory job where you tighten the same bolt all day long, where a touch too much or too little torque makes no difference. It requires independent thought, which in turn requires the people doing the work to take pride in it. Furthermore, it’s easy to do something the wrong way and have it work just well enough to end up in production. That “little error” you turn a blind eye to since it doesn’t seem to cause any problems will cause problems. Programmers who do not treat each project as something to be proud of turn out poor quality work, which in turn makes their careers short-lived.

#9: You prefer to shoot first and ask questions later

Software developers, at least the good ones, spend a lot more time planning what they’re going to type than actually typing. Usually, when coders just open up their code editor and start banging away at the keyboard, most of what they write gets ripped out later. Programmers who ponder, think, consider, and plan write better code in less time with fewer problems. There’s a reason so many programmers barely know how to type properly: The hard part of the job is knowing what to type. People who do not invest the time up front in their zeal to get started with the “real work” are actually skimping on the “real work.” If you are a doer and not a thinker, software development is probably not a good career choice for you.

#10: You do not like the geek type of person

For a bunch of reasons (some legitimate), a lot of people just do not enjoy being around the engineer or techie personality. If you have a hard time with the Dilbert or Weird Al personality type, do not even consider going into programming. Are all developers like that? Of course not. But they comprise a large enough portion of the workforce that you would be miserable in the industry.

courtesy @ TechRepublic

fetched from blog4aurobindo(blogspot)

The programming paradigm needs an update

The way I view programming is different than it was a week ago due to various factors. First, I have spent a lot of time lately with my head buried in the .NET documentation, and something in the back of my mind said, “If C# is so much more efficient than VB.NET, why do all of the code samples appear to be the same length and look virtually identical?” Then, I reread an e-mail from someone telling me that XYZ language was awesome because it needed dramatically less source lines of code (SLOC) to do the same thing as more mainstream languages. And, I have still been multithreading the same dumb little piece of code. Finally, I read a post by Mark Miller about Emacs and Lisp.

It is all coming together for me now, the conscious understanding of what I really dislike about programming. I got into programming because I like solving problems, but solving problems is really only a small fraction of the work. The rest of it is giving exact, precise details as to how to perform the tasks that solve the problems. It is like painting the Sistine Chapel by putting a seven-year-old boy on a scaffold and dictating to him every stroke you want him to make. It is ridiculous.

This highlights the real problem in the programming industry: Everything we slap on top of the development process is more garbage on top of a rotting foundation. Let’s take a closer look at what we do here, folks, and examine how much the programming paradigm has (or has not) changed.

Then (i.e., 10 -20 years ago)
A programmer sits down and analyzes the process of the work. Using a stencil and a pencil, he lays out a workflow on graph paper. The programmer sits down, fires up his trusty text editor (if he is lucky, it supports autoindent), and creates one or more text files containing source code. He then compiles the source code (or tries to run it through an interpreter) to check for syntactical correctness. Once it compiles or interprets correctly, he runs it with test cases to verify logical correctness and to check for run-time bugs. Any bugs are logged to a text file; or maybe he has a debugger or crash dump analyzer to find out what went wrong. This continues until the program is considered complete.

Now
A programmer sits down and analyzes the process of the work. Using a flowcharting tool or maybe a UML editor, he lays out a workflow. The programmer sits down, fires up his trusty IDE (if he is lucky, it supports version control), and creates one or more text files containing the source code. Some of this code may be auto-generated, such as data objects based on the database schema or some basic code from the UML. Half of this generated code will need to be discarded unless the project is very basic, but at least it is a start. The IDE will handle the basics of getting a form to display regardless of whether it is a desktop app or a Web app. The programmer then compiles the source code (or tries to run it through an interpreter) to check for syntactical correctness. Once it compiles or interprets correctly, he runs it with test cases to verify logical correctness and to check for run-time bugs. Any bugs are logged to a text file; or maybe he has a debugger or crash dump analyzer to find out what went wrong. This continues until the program is considered complete.

Wow… we’ve traded in vi for Visual Studio and a bunch of print statements for [F11]. At the end of the day, nothing has really changed except for the tools, which are barely keeping pace with the increasing complexity of developing software. We are stuck, and we are stuck badly.

The Lisp advocates like to say, “Lisp would have taken over if only we had better/different hardware!” Now we have the hardware, and Lisp is still not taking over. I assert that we need to go far beyond something like Lisp at this point; we need to get into an entirely new type of language. A great example of this is multithreading.

IT pros usually say two things about bringing multithreading work mainstream: Compilers need to get a lot smarter before this can happen, and we cannot make the compilers smart enough for this to happen well. If this seems like an irresolvable contradiction, it isn’t. The problem is not the compilers — it’s our paradigms.

If you’ve spent a fair amount of time with multithreading, you know that it will never become a commonplace technique until the compiler can handle most of it automatically. The fact is that it’s tricky for most programmers to keep the details of a system where concurrency is an issue — and debugging these systems is a pure terror.

Smarter compilers are the answer, but there is a truth amongst the compiler folks that compilers will never get that smart. Why? Because properly translating a serial operation into a parallel one requires understanding the code’s intentions and not just the step-by-step how to guide that the source code models. I can read your code and (provided it is clear enough) understand probably 80% of your intentions up front and possibly figure out an additional 10% or 15% of your code with time. The other 5% or 10% will be a mystery until I ask you.

Read the comments on this post from Chad Perrin about Python and Ruby; these people are trying to optimize a trivial chunk of code. What is even more interesting is the point Chad makes over and over again in his responses (he posts as apotheon): Maybe the intention of the code was to produce that onscreen counter that is eliminated in most of the optimizations. Or maybe, despite it being slower due to the concatenation of immutable strings, there was a knock off effect of that as well. Who knows? The intentions cannot be made through code without having ridiculously verbose comments in the code or having an exacting product spec available.

Perl appears to understand intentions, but it is a trick. Perl was simply designed to make certain assumptions based on the way most programmers usually think in the absence of logical code. If your intentions do not square with Perl’s assumptions, it either will not run, or it will not run properly. If you do not believe me, try abusing Perl a little with a record format that specifies the tilde as a record separator instead of newline. Perl’s assumptions fly out the window unless you set the record separation string in your code; and, at that point, you are no longer actually using the assumptions — you are giving it precise directions.

I am all for self-documenting code. I like to think that no one reading my code had to struggle to figure out what it does. But aside from design specs and/or pages of inline comments, there is no way for someone reading it to know why I wrote the code that I did. It is like being in the Army. They usually don’t tell you why you need to march down a road, they just tell you to do it.

Programmers are in a bind. Without a way for the compiler to know the design specifications, the compiler cannot truly optimize something as complex as a parallel operation beyond really obvious optimizations. There are no hard and fast rules to making a serial operation parallel; it is a black art that involves a lot of trial and error even for frequent practitioners. In order for the compiler be able to understand those design specifications, it would require an entirely different type of language and compiler. Assertations and other “design by contract” items are not even the tip of the iceberg — they are the seagull sitting on the iceberg in terms of resolving the issue. If the compiler is smart enough to understand the design document, why even bother writing the code? UML-to-code tools generally try to do this, but they do not go far enough. At best, these tools can translate a process into code that literally expresses that process; there is no understanding of intention.

There are a few major schools of programming languages — object oriented, procedural, functional, and imperative — all of which have their strengths and weaknesses. Functional and imperative languages come the closest to what I am talking about. SQL is a great example. You tell it what you want not how to get what you want. The details of the “how” are up to the database engine. As a result, databases are optimized in such a way that they run a lot faster than what 99.9% of programmers could get the same stuff to run (not to mention redundancy, transactions, etc.) despite their rather general purpose nature. Even SQL shows a lot of weakness; while it is an imperative language, it is extremely domain specific. As soon as you want to manipulate that data, you land yourself in the world of procedural code either within a stored procedure or your application.

Most applications (and every library) become a miniature domain specific language (DSL) unto itself — not syntactically (although some, such as regex libraries, reach that status), but in terminology, subject matter, and so on. The problem you are most likely trying to address has absolutely nothing to do with the language you are using and everything to do with a specific, nonprogramming problem.

A great example of the disconnect between code and the problem it addresses is the subject of loops. I bet over 50% of the loops out there go over an entire data collection and do not exit without hitting every single element in the collection. The logic we are implementing is something like “find all of the items in the collection that meet condition XYZ” or “do operation F to all items in the collection.” So why are we working with languages that do not deal with set theory?

Programmers end up implementing the same thing over and over again (i.e., a function or object or whatever in a library that takes that big set as the input) and implementing a filter command that returns a smaller, filtered set, or an “ExecuteOnAll” method that takes a pointer to a function as the argument.

When the language folks try to make it easier on us, the result is stuff like LINQ, the welding of a DSL to a framework or language to compensate for that language or framework’s shortcomings in a particular problem domain.

The only way LINQ could get implemented is if the languages that support it have closures, which are “the thing” in a functional language like Lisp; closures are even important in Perl. But programmers have been working in Java and Java-like languages for the last five – 10 years (depending on how much of an early adopter you were), and a lot of folks missed Perl entirely, either sticking with VB and then the .NET languages or starting with C/C++ (or Pascal) and going to Java and/or .NET. The only exposure most programmers ever had to a truly dynamic language is JavaScript (aka ECMAScript). (By dynamic language, I mean a language that can edit itself or implement or re-implement functionality at run-time. JavaScript, with its support for eval(), has it and so does Perl. In functional languages like Lisp, this is all the language really can do.) In reality, JavaScript is not that bad; in fact, I like it quite a bit. I am just not a huge fan of the environment and object model programmers are used to seeing it in (the browser DOM).

Most of the programmers I have dealt with have little (if any) experience with a dynamic language. The result is that they don’t have the ability to think the way you need to about a dynamic language. These programmers stumble around blind; they intuitively know that they aren’t working to their potential, but they have no idea where to start. (Why else would there be the huge market for code generators and other gadgets to improve productivity by reducing typing?)

I do not believe that Lisp and its ilk are the answer; they are too difficult for most programmers to read through and understand, and the entire code is a back reference to itself. Procedural languages have also proven hard to maintain. Object-oriented languages are the easiest to maintain — at the expense of being insanely verbose, which is another reason for the code generators. Imperative languages are almost always going to be little more than DSLs.
Where do we go from here?

I want to see programmers headed towards intentional languages. I have no idea what they would look like, but the source code would have to be a lot more than the usual text file and would need to be able to express relationships within the data format, like XML or a database do. The programming paradigm needs to be able to quickly reduce any business problem to an algorithm so that the real work can go into writing the algorithm and then, at the last minute, translating the results to the domain’s data structures again. The programming paradigm would look like a mix of a lot of different ideas, but syntax and punctuation would have to be fairly irrelevant.

What are your thoughts about the programming paradigm? What direction do you think it needs to take?

fetched from blog4aurobindo(blogspot)

Sun says farewell to mobile Java

According to James Gosling, often called the father of Java, the Java Micro Edition (ME) will gradually supplanted by the Java Standard Edition (SE). He said, “We’re trying to converge everything to the Java SE specification. Cell phones and TV set-top boxes are growing up.”

The idea is that mobile devices are packing ever increasing amount of processing power – enough to handle all the demands of full-featured Java.

Excerpt from News.com:

Sun’s Java expectation dovetails with recent trends, most notably Apple’s iPhone, which architecturally is much more an Apple computer writ small than a mobile phone writ large. In particular, Apple uses a version of its regular Safari Web browser so users will have as much of the desktop Internet experience as possible.

To be clear, the move to Java SE won’t be happening overnight. Smart phones using various pared-down versions of Java is expected to stay in the market for at least a decade. But the shift is already under way.

courtesy @TechRepublic

fetched from blog4aurobindo(blogspot)