Friday Mar 24, 2006

ajaxWrite: word processing via ajax

It seems that almost every day there are cool new ajax tools coming out and providing powerful web applications that can almost replace all those old desktop applications you still use. For example there is ajaxWrite which is a nice and simple word processing application, right through your browser. Note, no registration required. Just launch the app, edit away, and you're done.

Supposedly Writely is even more feature rich, but I can't register to find out right now.

Monday Feb 20, 2006

Throw exceptions, don't return null

One of the simple coding practices that has become a pet peeve of mine over the years is the reluctance of most developers to throw exceptions. I find that many developers still like to return a null value rather than throw an exception and thats something that needs to change. There are certainly going to be situations where returning null might make some sense, but most of the time you should be throwing exceptions.

I found a fairly short article titled Diagnosing Java Code: The Null Flag bug pattern which does a pretty good job of illustrating the potential pitfalls with the null flag pattern.

One place where I see the null flag pattern used in one of the worst scenerios is with DAOs. Many applications which access persisted data will setup a data access layer which provides classes and methods for creating, updating, deleting, and retrieving data. Very often the designers of this data access layer will allow their data retrieval methods to return null values rather than throw an exception. The big problem in this case is that presumably the caller of the method isn't just hoping for a value, they are expecting a value and when a value cannot be returned that is an error case. Rather than hope that the caller properly checks for a null return value an exception should be thrown.

I know how hard it can be to break old programming habits, but this is one of those very fundamental patterns which really deserves the extra effort. Trust me, you'll be doing everyone a favor by just throwing some more exceptions.

Tuesday Jan 03, 2006

asynchronous referrer processing

One of the new things I'll be working into Roller as part of the next batch of performance improvements will be the ability to process referrer information in an asynchronous manner, i.e. outside the http request/response cycle. Not of much importance to smaller Roller installations, but enterprise users should get a pretty nice performance boost. The official proposal page is here ...

http://rollerweblogger.org/wiki/Wiki.jsp?page=AsynchronousReferrerProcessing

Thursday Dec 22, 2005

caching the web

Chris Rijk pointed out some caching ideas in his comment on my last post about some of the changes that went into Roller 2.1. I was going to respond as a comment, but it got a bit too long so I decided a new post was more appropriate.

Chris,

I agree that caching data is one way to solve the problem, but it is not the only way. I tend to consider three general approaches to caching in web applications, each has it's own benefits ...

1. Data Caching. As you mentioned, this means caching your objects rather than caching rendered content and you can quickly access those cached objects to render a page. This approach is ideal for very dynamic content which could be changing at any minute, like a discussion forum. However, with this approach you also spend time doing rendering on each request, which lengthens your request processing time.

2. Cache small pieces of rendered content. This is the portal approach where you are rendering lots of little bits of content and caching that, then pulling multiple pieces of your cached content together to make the full page. This is a great approach when your content is only semi dynamic, yet needs to be reused in many different ways on different pages. Unfortunately this is typically the hardest cache system to implement and requires a great level of caching control.

3. Cache fully rendered pages. This is the easiest approach and typically the fastest, you simply render the page and cache it as a whole. The problem with this approach is that your pages can't have any truly dynamic elements that change per request.

I think that depending on your application, how dynamic the content is, and how much content and memory you have you will choose some combination of the three of these cache methods.

Now, to relate this specifically to Roller. The caching in Roller is basically completely #3 at the momement primarily because the content on a weblog really isn't that dynamic. Remember, a weblog is really just a fancy name for "website" with a really easy publishing system built in. We could possibly use option #2, however our problem is that all the weblog content is user controlled via Velocity templates, so it's hard for us to figure out what pieces of content to cache. And we could definitely use #3.

There will certainly be a places in Roller where data caching is ideal, but for right now we'll probably stick with caching the fully rendered content. Our biggest problem is really just memory, we need more room for our caches as the site gets more and more content and that problem won't change whether we're caching pages or data.

Wednesday Dec 21, 2005

Wrapping up Roller 2.1

Well, the Roller 2.1 release has happened rather quickly and we are now just wrapping things up and preparing for release.

You can see what Roller 2.1 has to offer on the Roller 2.1 proposal page.

The new caching code was my big contribution to this release and so far I'm pretty happy with it. blogs.sun.com has grown very rapidly over the past few months, so naturally performance quickly becomes a big concern. Probably the nicest thing about the new caching code is that it's easier to plug in new caching implementations and it's also a little easier to separate content into various caches now.

For Roller 2.1 I added a non-expiring cache implementation, which is ideal for things like xml feeds which don't change often. I've also separated some of the content into more caches, namely taking the old page cache and splitting it into a main page cache and a weblog page cache. This is helpful because under the old implementation the main page can get pushed out of the cache if your cache isn't big enough, and that sucks because the main page is probably the most time consuming page to render. We've also pushed all the planet content into it's own cache, which guarantees that the planet pages get some caching priority as well.

There is still some work left to be done with the weblog page cache, which caches all the page content for each individual weblog. Unfortunately, on a large site like blogs.sun.com with 1800 bloggers, the number of possible unique pages is very high. Considering 1800 bloggers with 100 entries each, our possible page count would be well over 180,000 pages, which is way more than a simple webapp can cache itself. So it's time to start looking into how we could make that happen.

Friday Dec 16, 2005

Scheme enforcement in Java Webapps using an ssl accelerator

If you've ever used an ssl accelerator with a webapp then maybe you've come accross this problem where your application is effectively incapable of determining which requests are secure versus insecure.

The Problem: When using some form of proxied solution for doing ssl transactions (an ssl accelerator, ssl proxy, etc) the http request that is processed by your application server is unaware of whether or not the original request was processed by your ssl handler. If an application cannot determine which requests are secure versus insecure then it cannot handle scheme enforcement and scheme switching for things like secure logins and registrations. Example ...


request -> https://mysite/index.jsp (ssl handler) -> http://mysite1.server:8080/index.jsp (app server)

This is a very common scenerio, where there is a proxy setup to handle ssl requests before they get to an application server because the proxy can do ssl handshaking much faster than an app server. The problem that arises in this scenerio is that the app server gets the request from the proxy and does not know if the request was originally over ssl or not. More specifically in a Java webapp this means that the value of request.isSecure() will always be "false" because the application server sees the request as a simple http request. This is a problem if your application tries to ensure security for any of its resources.

Possible Solutions: Unfortunately there doesn't seem to be a fix-all solution to this problem, at least not as far as I have seen. The solution is largely dependent on what application server is being used, how the ssl proxy is setup, and how your application is trying to use it's https vs. http protocol switching.

Tomcat offers a fairly easy way to tackle this problem by allowing users to manually specify that all requests on a given connector are secure vs. insecure as well as setting the scheme to https vs. http. Using this approach you simply configure tomcat to have 2 connectors running on different ports, 1 for http insecure connections, the other for https secure connections. For the https secure connector you just need to set the appropriate properties ...


<Connector port="8080" scheme="http" secure="false" />
<Connector port="8043" scheme="https" secure="true" />

Then just setup your proxy to forward insecure requests to tomcat port 8080 and forward ssl handled requests to tomcat port 8043.

If you aren't using tomcat or don't want multiple connectors then an alternative is to try using a custom http header. Often times it's not too difficult to have your proxy set a custom http header for requests that were handled over ssl and if so then all you need to do is enable your application to be aware of that custom header. The easiest way to do that is to define a simple class like MyRequestWrapper which overloads the servlet request.isSecure() method to inspect the request for your custom header. Then use a Filter to wrap the incoming request in your MyRequestWrapper.

I'm sure there are many other alternative ways to tackle this problem, but these two solutions should work for quick a few situations.

Thursday Nov 03, 2005

The not so private privacy of Java

Today I discoverd that a private variable in Java didn't mean exactly what I thought it meant.

We recently ran into a bug in Roller that was derived from the fact that Hibernate 3 doesn't like it when you access member variables directly rather than through bean style getXXX() methods. The reason for this is because Hibernate likes to use proxies and lazy loading to fetch data only when it thinks it's needed. While debugging this problem I discovered that the "private" keyword in Java worked a little differently than I had thought.

Up until now I had believed that "private" meant that access was limited to within a given object, i.e. an instance of a Class. However the truth is that "private" only limits access to a Class and whether or not the Class has been instantiated is irrelevant. example ...

public class Foo {

  private String myAttribute = null;

  public String getAttribute() {
        // maybe I want to perform some logic here?
        if(this.myAttribute == null || this.myAttribute.length() < 1) {
                return "you need to set a value for this attribute!!";
        } else {
                return this.myAttribute;
        }
  }

  public void setAttribute(String attr) {
        this.myAttribute = attr;
  }

  public void someMethod(Foo otherFoo) {

        String memberVar = null;

        // this directly accesses a member attribute of the object passed in
        // I had thought this was not possible
        memberVar = otherFoo.myAttribute;

        // this is what I would normally do and until today
        // I had thought this was required
        memberVar = obj.getAttribute();

        // or maybe you prefer to write data?
        otherFoo.myAttribute = "huh?";
  }

}

I'm not sure why I had never realized this before, it's actually written very plainly in the Java Tutorial ... "A member's access level determines which classes have access to that member, not which instances have access."

What I am wondering now is, why not provide some kind of instance privacy? Wouldn't it seem like a good idea to allow an instance to shelter it's member attributes completely? I suppose there are very few cases where the situation I mentioned above would cause problems, but still, for some reason I feel like I've lost some privacy.

Wednesday Aug 31, 2005

Save Blastwave!

I've just heard from Hoffie that Blastwave.org is having financial problems and may have to close down.

If you want to support the site then head over to Blastwave.org and help out by taking part in the survey and donating whatever $$ you can. This is a great resource that the Solaris community does not want to lose.

Sunday Jul 31, 2005

Interesting read: Data First vs. Structure First

A cool article about design ... Data First vs. Structure First

Wednesday Jul 27, 2005

Convert Line Breaks Plugin

Finally! I no longer have to add all those damn <p> and <br> tags in my posts!

I wrote a plugin for Roller that will allow users to write their blog posts in plain text and simply apply the convert line breaks plugin to have the text wrapped in html "p" and "br" tags. Oh the convenience ;)

Tuesday Jul 26, 2005

solaris networking: basic config

One of the things I always seem to forget when using my Solaris workstation is simple config/setup stuff. This is undoubtably because I typically get my workstation setup how I like it and never have to mess with it again for years. However, when the time actually comes to do the setup again I always have to sift through mounds of google queries in order to get things working again :/ This time I'm going to try and document some of the little gotchas that come up and record them here.

This morning I was helping my new officemate setup networking on his workstation and I thought "sure, I know how to do that." Well, I \*sorta\* knew how to do it, but of course I left out a couple key steps.

Here it is. Basic networking using a static ip/hostname ...

# lets assume the ip is 200.0.0.22 and hostname is "foo"
# setup interface (interface is usually hme0 or bge0)
vi /etc/hostname.hme0
--
foo
--

vi /etc/hosts
--
200.0.0.22 foo
--

# set default route (depends on your network)
vi /etc/defaultrouter
--
200.0.0.1
--

# set netmask (depends on your network)
vi /etc/netmasks
--
200.0.0.0 255.255.255.0
--

# set dns resolution
vi /etc/resolv.conf
--
domain your.domain
nameserver [primary dns server ip]
nameserver [secondary dns server ip]
--

# enable dns resolution for hosts
vi /etc/nsswitch.conf and add "dns" to the line with "hosts: "

Maybe there is an easier/better way to do it, but this was enough to get his machine properly on the network.

Monday Jul 18, 2005

to dhtml or not?

I've gotten into this discussion with a friend of mine several times and strangely I'm still not exactly sure of my position on the topic. My buddy works on some very media centric sites which deliver on demand videos, etc, and so he uses dhtml a lot to make the interface faster and more interactive. My background is much more simple and geared toward the server side because most sites I work on don't have any real need for fancy bells and whistles that require dhtml. He tries to convince me that dhtml is the wave of the future and that everyone is going to be doing it soon. I represent the counter-point that sites which don't \*need\* dhtml won't use it and that includes most sites on the web.

I totally acknowledge that sites like google maps have used dhtml brilliantly to provide functionality above and beyond what was possible before, however I also believe that applications like google maps are particularly well suited for a more elaborate and interactive experience which dhtml can provide. On most websites I still find that typical uses of dhtml are just fluff and hardly provide a leap in real functionality and in some cases the dhtml just gets in the way and breaks things which probably should have been done in html. It's a tough call, I definitely see some great potential in the combination of dhtml and xml, however I would still be reluctant to rely on it for anything.

I am curious what others think about this. what is dhtml's place on the web? what are other good examples of dhtml being really effective?

Wednesday Jul 06, 2005

Roller 1.2 Released

I almost hadn't noticed, but Dave put the final touches on the Roller 1.2 release last week and now it's available for download. The big new features being a redesigned config system to make installations easier, the new ping tools, and lots of little bug fixes.

I am happy to say that work on Roller seems to be in pretty high gear right now and things are moving along very smoothly. Just around the corner we have some pretty cool new features like sharable themes and group blogging which are sure to make users happy.

Monday Jul 04, 2005

the obsession

Well, phase 1 of the new Roller theme management code is pretty much ready. I'm pretty excited because the coding went pretty much exactly as smooth as I had hoped and usually you leave a bit of extra time assuming that something will go wrong and you'll hit a few bumps in the road. Well the bumps turned out to be mere pebbles this time around and with a little coding this weekend I was able to get things pretty well wrapped up.

I know we are supposed to be on july break now, but I can't help it, I obsess about code. I can't leave code unfinished. Once I get started on a chunk of code there is just no turning back because no matter where I go or what I do my mind will be fixated on coding basically until I've finished the feature or fix. I had planned to have things in a good state when I left for break on Friday, but unfortuantely there were a couple of unexpected hold ups on other projects at the end of the week which altered my schedule and I just couldn't help but finishing things up.

I'll probably commit the new code tomorrow after a few more checks and now that I'm a little ahead of schedule I can look at rolling in some of the theme management v2 features already :D

Tuesday Jun 21, 2005

Better Theme Management

Okay, now that I don't have to spend quite as much time on Opensolaris I can get back to working on improvements for blogging here at Sun.

For those that are interested there is a new technical proposal on the table for making some improvements to the current state of theme management in Roller. This is mainly written for other Roller developers, so it's probably a bit technical for non-java programmers, but feel free to take a peak and leave comments if you like.

We are hoping this can be completed for the next BSC release which is scheduled for late July.

About

gconf

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
News

No bookmarks in folder

Blogroll

No bookmarks in folder