Can you program without coding?

Do you think you can program without coding? I never would have thought so, but now I do. It's possible to make user-defined types and interfaces, call services, create a service, make a deployment artifact, deploy and test-- all without writing a single semi-colon, angle bracket, or curly brace.

You don't believe it? It's true! I've been working with SOA toolkits from several vendors over the past several months, and have been deeply impressed by how much behind-the-scenes coding can be abstracted away from the coder. Check these out:



Defining a user-defined type (This picture shows Intalio, one of the less expensive UIs)

Define a user-defined type (similar to a class)
Using the UI, you click an icon to 'add a field'. You type in a name for the field, then choose a type for the field. The available types are XML types-- string, int, long, etc. (Or user-defined types you've earlier declared.) Behind the scenes the UI will build you an XML schema (XSD). The nice part? The XML is well-formed every single time, without any hand-coding of the XML!

Define an interface
A few clicks of a button lets you declare a new interface. You choose the input and output types from XML primitives and the user-defined types you have made.


WSDL, used graphically to call partner web services

Call Web Services
You import references to external services from a registry or directly from the wsdl offered by that service. This will give you a UI widget you can then drag onto your canvas to call the service.

Declare a service
Once you have your interface defined and the business logic (declaring variables, calling services, etc.) defined, you can generate an implementation for that service. This makes your logic available (usually as HTTP/SOAP, JMS, etc.)

Branches
Again, using UI figures you place a branch in your logic and indicate through XML XSDs how to decide which path your code should follow. (Of course you don't actually see XML, you see grid boxes of field names, you click on the one you want.) You can make loops in a similar fashion.

Make a deployment artifact
You can choose to 'export' your business logic as a .JAR or .EAR. Without any scripting, your IDE will produce an artifact ready to deploy.

Test your logic
Some of the high-end tools come with embedded application servers. This allows you to seamlessly deploy your component and test it right from the IDE.

You can do all this, and more. So what does this mean to us?

I have no doubt these toolkits will continue to get better and more refined as time goes on. It is already possible to be a productive programmer without writing any traditional code or actually seeing any XML.

But the main point is this-- the person doing this programming still has to think like a coder. You still have to know when you need a variable, have to understand primitive types (long, int, etc.), still have to understand how a loop works, etc. Perhaps most important, you still have to think in a logical and methodical way. For this reason, I am actually optimistic about these developments-- I think it's just making a programmer more productive.

So how do you get started? For no money, I'd suggest you have a look at Intalio BPM. This freely available toolkit will let you validate what I've said here and get some idea what these toolkits can do.

Happy (Codeless, this time) Programming!

Packt Plone double-whammy

Packt Plone double-whammy





Have you tried Plone? It's an open source content management system that can be used as the basis for many kinds of websites. Plone strong points are its flexible and adaptable workflow, very good security, extensibility, high usability and flexibility. Sound interesting? If so, you're in luck. I'll be reviewing 2 new Plone books in the near future and you have the opportunity to purchase Plone books at a discount.

The first new book is "Plone 3 Products Development Cookbook", which promises 70 Plone recipes, and can be found here:


The book offers a sample chapter, it reads cleanly and clearly.


The second book is "Plone 3 Multimedia", which tells how to build a media-rich website with images, audio, video, and Flash.
The book is found here and a sample chapter is here.

In addition to the special pricing (discounts of 20% on print books and 30% on e-books) my friends at Packt tell me they'll be offering a chance at a 'lucky draw' iTunes or Amazon gift card to early purchasers of these books. I'm not privvy to exact details of that part of the promotion, so watch the web site for that one.

The special offer is detailed here.

I look forward to providing reviews on this blog in the near future. 'Till then,

Happy Reading!

'Enterprise' 101 - Location Transparency

Let's say you wrote a nice service, something like getHello(), and put it on a server. Now you want to write your client and use it to invoke your service. If you're following most development cookbooks, you're writing some code like this:




public class TestClient {
public static void main(String [] args) {
try {
String endpoint =
"http://ws.apache.org:5049/axis/services/echo";

Service service = new Service();
Call call = (Call) service.createCall();

call.setTargetEndpointAddress( new java.net.URL(endpoint) );
call.setOperationName(new QName("http://soapinterop.org/", echoString"));

String ret = (String) call.invoke( new Object[] { "Hello!" } );


So what's wrong with that, you ask? Your code is going to work-- your client will be able to call the server. But you're missing an important ingredient-- Location Transparency.

The client code you see above is less than Enterprise-worthy because the service endpoint is embedded directly in the client source code. What happens when the server has a hardware failure and needs to be replaced? Your client code will be irreversably broken and will need to be recompiled. Also, you are confined to hitting one service from your client-- if the server becomes a bottleneck, you don't have a good way to scale out.

Location Transparency-- the Registry solution

One solution to the Location Transparency problem is to use a registry to find your server. The registry is a well-known place where servers are registered and clients go to ask locations of servers. UDDI is the 'spec' answer for web services, though it hasn't worked out as well as the spec writers probably would have liked. Today there are other web service-centric registries that serve the same purpose as UDDI, but offer 'value adds' from the implementors. In the CORBA world, you might use a 'Name Service' to act as your registry. Still others might code their own registry using a database or some other CRUD data store.




Here are some pros and cons of a registry solution:

Registry Pros
- Allows loose coupling between client and server
- Can be implemented in a way that lets the client 'discover' services based on attributes like method arguments

Registry Cons
- Does not take into account servers that crash. If a server is registered then crashes, the registry will still steer clients toward the dead machine.
- Does not make a provision for load balancing. A registry isn't usually charged with telling a client which like-typed server to run against-- it just provides a list of the servers.

Niceties
- If you can code your services to self-register with the registry when they start, that's a good thing. Your operational admins probably have better things to do then key new services into the registry.
- You'll also want the services to self-unregister when they come down gracefully. Note that this doesn't help a crashed server, though.

There are other ways to address the Location Transparency problem, though-- through Messaging and through a Load Balancer are a couple of good ones. But those are posts for another day.

'Till then,

Happy Coding!

Book Review "CodeIgniter 1.7 Professional Development"

This book is a good introduction to the CodeIgniter library. CodeIgniter is a multi-purpose PHP library that contains a lot of good functionality and is easy to use. This book is a survey-level guide to the library, accompanied by a great many easy to read code snippets that help the reader understand CodeIgniter usage.

Here are some of the topics I found most useful:

- MVC programming
- PHP Style
- Benchmarking (timing ticks)
- Input and security
- Email
- File Upload
- Pagination
- Session management
- Database interaction (to include 'Active Record' implementation)
- User Authentication & Security
- Tips on building a large-scale application
- RESTful Web Services
- Extending CodeIgniter and sharing back with the community

I found this book to be an easy read. I've done a little PHP coding, but not a great deal, so I really appreciated the easy to read code snippets that accompanied nearly every topic. The book covers a lot of territory, so there's not a great amount of detail on any of the covered topics, but there is enough material to give you a taste of what the library holds. If that's not enough to help you implement what you need, at least you're aware of what CodeIgniter can do for you.

The book's back cover says this is a book for advanced PHP developers, but I'm not sure that's the right target audience-- I'd expect a true expert might feel they're getting too little advanced material here. For newbies to mid-level PHP coders, though (like myself) I think this book does a great job of introducing the types of things you can do in PHP and some really easy code examples to leverage.

If you've got an interest in PHP and are looking for a good library to let you write advanced web site functionality easily, I'd encourage you to check out "CodeIgniter 1.7 Professional Development". You can find it here.

Happy Coding!

Simplicity Drives the Net's Most Popular Framework

Do you know which framework is dominant on the web? Have a look at this chart to see which frameworks are hot, and which are not.



You can check the current stats whenever you want here:

I was somewhat surprised to read those statistics. I would've thought some of the less popular frameworks would've done better, and I would've thought some of the most popular wouldn't be doing so well. I started thinking about why PHP is doing so well, and I've drawn the conclusion that it's the amazing simplicity. (To be sure, the made-for-the-web functionality has a large part to do with it, but other frameworks offer that, too.) Here are a few of the things I think make PHP easy to use:

- No compiles or compiled artifacts to shuffle around
- No complicated configurations to master, no lengthy XML files to edit
- As simple and procedural as you want it to be
- Plenty of power, if you need it. If you don't, only blissful simplicity
- Easy language syntax. To me, it reads something like plain old C.
- Everything's in one place -- You can just mix Server-side scripting right there with your HTML pages (Wow, that flies right in the face of the justification for JSPs and ASPs, doesn't it?)
- Fantastic iterative cycle-- you make a directory and edit scripts with GEdit/Notepad/Vim/etc, then check it in the browser. Nothing could be simpler!

Here's an example:

<html>
<head>
<title>My First PHP Page</title>
</head>
<body>
<?php
echo "Hello World!";
?>
</body>
</html>

What could be more simple than that?

If you haven't tried PHP, I'd urge you to do it. It really can be fun.

How do you get started?

1) Get a web server that's PHP enabled. (You can search the web for any of the pre-packaged stacks. I use the excellent EnterpriseDB PostGres/Apache/PHP stack found here)

2) Find the web root for your web server. For my Apache installation, it's called 'www'. Put a new directory under that one, and add a simple PHP script to that directory. (Maybe the hello world above. Put it in a file called 'Hello.php' or something like that.)

3) Point your browser to http://localhost://Hello.php Maybe something like http://localhost:8080/HelloExperiment/Hello.php

4) Edit the file to add more PHP and watch the results change in your browser as you refresh. That's it!

The web is full of great sites on PHP, including the excellent www.php.net. Read/Edit/Watch the change!

I love this simplicity, don't you? That's something we could all use more of.

Happy Coding!

Every programming language should have a tool like Acire!

I updated my laptop to Ubuntu Lucid Lynx last week, and along the way I picked up a few new tools. One of these is 'Acire', a learning utility for Python.

Acire is a great idea-- you can browse code snippets for topics you're interested in, view some simple source code, and observe the execution all in one 3-pane window. Simply put, it makes for a very easy reference library for Python and a great way to learn more about the language.




Acire is packaged for Debian, and I'm not sure if it runs off Ubuntu. (I print this to save you time if you're not an Ubuntu user.) I wish it would run everywhere, and I wish even more for this to be available in multiple languages. It's a great learning tool!

Acire can be found here:
http://www.jonobacon.org/2010/01/12/acire-0-2-released/

For those of us who can use it, enjoy!

Happy Coding!

4 Ways To Become a Better Developer, in No Time

If you're like me, you're working hard to find the right work/life balance. In that game, I think any little edge can be of value. Here are 4 tips I use to self-improve without sacrificing any time from the 'personal' side of the ledger.

Multi-purpose your MP3 player
If you have an MP3 player, put some tech-talks on it as well as music. Then when you're out doing something that allows effective multi-tasking, listen to them. I like to go running, on some days I'll listen to a podcast on software engineering. Google will help you find lots of good podcasts, one of the best sources is "Software Engineering Radio", found here.

Put a tech book (or at least tech tutorial printout) in your car
There are going to be times when you end up waiting somewhere-- these are ideal times to read material you just might not have time for otherwise. Probably my favorite example is a shopping trip. My wife loves to shop, I hate it. But now I just leave a tech book in the car, which I take out only after we get to the store we're driving to. Once we're there, I let her go through the store while I catch up on my reading. Then when she's done at that store, I put the book down as we talk and drive to the next place. Everybody's happy! (Warning: We programmers can be overly focused sometimes, which can lead to spousal displeasure. Be cognizant of the fact that you shouldn't keep reading once your spouse returns to the car!)

Take a book to the Oil Change
If you're like me, you've got two cars in the family. That means every 3 months somebody's going to be going to the shop for at least an hour-- twice! To make these waits more bearable, I've started taking a book in with me. The same technique works well at the doctor's office-- sitting in the waiting area for my checkup can be time well spent!

Leave a 'Boot-Up' Task for Tomorrow
My work laptop takes a long time (several minutes, at least) to boot up. This isn't because the machine is overloaded or needs a cleanup-- it's because this is when corporate IT pushes scripts and patches onto the box. I like to leave myself something to work on while this is going on-- a small diagram reminding myself what I was working on, a tech document, a to-do list to think about, etc. Then when my machine is busy waking up, I can start getting myself back into the right mindset.

I'm sure there are a lot of other ways to effectively use time that would otherwise be spent unproductively. If you've got a favorite, please leave it as a comment.

Happy Coding!