Matt RaibleMatt Raible is a writer with a passion for software. Connect with him on LinkedIn.

The Angular Mini-Book The Angular Mini-Book is a guide to getting started with Angular. You'll learn how to develop a bare-bones application, test it, and deploy it. Then you'll move on to adding Bootstrap, Angular Material, continuous integration, and authentication.

Spring Boot is a popular framework for building REST APIs. You'll learn how to integrate Angular with Spring Boot and use security best practices like HTTPS and a content security policy.

For book updates, follow @angular_book on Twitter.

The JHipster Mini-Book The JHipster Mini-Book is a guide to getting started with hip technologies today: Angular, Bootstrap, and Spring Boot. All of these frameworks are wrapped up in an easy-to-use project called JHipster.

This book shows you how to build an app with JHipster, and guides you through the plethora of tools, techniques and options you can use. Furthermore, it explains the UI and API building blocks so you understand the underpinnings of your great application.

For book updates, follow @jhipster-book on Twitter.

10+ YEARS


Over 10 years ago, I wrote my first blog post. Since then, I've authored books, had kids, traveled the world, found Trish and blogged about it all.
You searched this site for "css". 327 entries found.

You can also try this same search on Google.

OSCON 2008 Wrapup

This week, I attended OSCON 2008 in Portland, Oregon. I talked to someone who thought the conference had a very small Java presence. I noticed this too, but that's how it's always been. Interestingly enough, they also thought it had a small Ruby showing. I guess Perl, Python and PHP will always dominate OSCON. Of course, there's nothing wrong with that. I've always admired OSCON for the diversity of developers and languages.

Below is a list of my entries for all the sessions I attended.

If you attended OSCON, did you enjoy the show? What was your favorite session? I'd love to hear other's impressions of the conference and how it could be improved.

Posted in Open Source at Jul 25 2008, 10:05:08 AM MDT Add a Comment

[OSCON 2008] CSS for High Performance JavaScript UI by Gavin Doughtie

Gavin is a front end developer on Google’s Picasa Web Albums and a contributor to the dojo toolkit. The original designer tools for Web 1.0 were the FONT tag, TABLE hacks and spacer gifs. Now we live in the future (shows a picture of the iPhone). Maybe it's time to accept that we're stuck with CSS. "I'm a coder, not a designer" is what happens at OSCON.

There are costs of JavaScript: development, download, parse time and runtime performance. It's extremely powerful and high-level, but it's slow because it's interpreted. Drawing a box with JavaScript in Firefox 3 isn't too difficult. Another way to do the same thing is with CSS. Doing the same thing in CSS is much faster and requires less code. Surrender To Win. You don't have to code it all. You can hand off part of that to your runtime environment (browser).

CSS Fundamentals
You want to how things flow in a page. Browsers were originally designed to render text. They're built to render flowing text. Other important fundamentals include float, positioning, negative margins, relative units, pseudo-selectors. Lastly, you need to know when to use tables. Gavin is now showing an example of using CSS to modify an image so it scales with the browser window. It's pretty simple:

body {
  margin: 0;
  padding: 0;
  height: 100%;
  width: 100%;
  overflow: hidden;
}

img { 
  position: relative;
  width: 100%;
  height: 100%;
}

Relatively Absolutely: "Absolute" in relative to position:relative. If an element has absolute positioning, it will only be positioned relative to it's parent element. To draw a box on an image, it's usually best to calculate the percentage position and sizes in script or on the server. The world's greatest psuedo-selector is :hover. Unfortunately, :hover doesn't work on anything but <a> in IE 6.

With floats, you can "float" elements to the top, right, bottom and left. In Firefox and Safari, you can set a border-radius to draw lines that are curved. Before Firefox 3, these lines where terrible looking.

Tables make a lot of sense when you have a grid layout. Use table-layout:fixed if you don't want table cells to be the width of their contents.

For sizing images and other elements, it's usually best to use em for the height and width and relative measurements. You can then use style.fontSize to resize the images. Using this technique is must faster than using JavaScript to set the height and width on an image.

WebKit, the CSS Wonderland. Gavin loves WebKit. It's on Safari (Windows, OS X and iPhone), Android, GNOME and KDE. With WebKit, you can build expanding lists w/o any coding. To do gradients in WebKit, you use:

background: -webkit-gradient(linear, left top, left bottom, from(#fff), to(#00abeb));
-webkit-border-radius: 0.24em;

To do animation, you can use:

-webkit-transition-property: width, height;
-webkit-transition-duration: 250ms;
-webkit-transition-timing-function: default;

Another thing you can do with WebKit is rotate images (using -webkit-transform: rotate()) and just about anything (divs, forms, etc.). WebKit also supports SVN masks, which means you can open up a hole and view an image through it.

Gecko's pretty cool too. Firefox 3 introduced a new rendering engine based on Cairo. You can do an SVG transform in Firefox 3 to create reflections of elements (divs) in your page.

"With browsers, you cut people off at the knees, but everyone's the same height." -- Alex Russell

IE 6 is not the problem, we're the problem. If you drop support for IE 6, you won't have to worry about coding towards it. It might not be possible if you work for a large company, but if you're small, you should definitely think about it hard.

It's funny to think that IE 6 is the new Netscape 4.

Gavin's slides from this talk will be available at http://xdraw.org/oscon2008.html in the next few days.

Posted in The Web at Jul 24 2008, 03:30:32 PM MDT 1 Comment

[OSCON 2008] Google XML Pages (GXP) by Harry Heymann and Laurence Gonsalves

GXP is a templating system that Harry and Laurence developed at Google. It was original created by Laurence in late 2001 (Java run-time, compiler written in Python) as part of the AdWords rewrite. I'm attending this session because I heard from a Google employee that they were using WebWork + their proprietary templating framework for the view. My suspicion is that GXP is that framework. The presentation I'm listening to is available at the following URL:

http://docs.google.com/Present?docid=dcbpz3ck_8gphq8bdt

Google XML Pages has the following features:

  • static type checking
  • convenient parameter passing/modularization system
  • partial markup validation
  • automatic escaping of untrusted content
  • encourages functional style, discourages side-effects
  • internationalization support
  • lightweight runtime

GXP is an open source project as of today and is available at http://gxp.googlecode.com. It's used by AdWords, AdSense, Checkout, Blogger, Analytics, Reader and many more.

HelloWorld.gxp:

<gxp:template name='com.google.sample.HelloWorld'
              xmlns:gxp='http://google.com/2001/gxp'>
Hello, World!
</gxp:template>

Output:

Hello, World!

GXP has compile-time markup validation as well as static-type checking. GXP has native data types: for text/html, text/plain, text/css and text/javascript. It supports loops, conditionals, abbreviations, internationalization (i.e. <gxp:msg>Hello, World</gxp:msg>) with placeholders. You can call GXP in the same package using <call:GXPName>. To call something outside a package, you can use <gxp:import> to import packages or classes. You can also use a qualified XML namespace to access another package.

Posted in Open Source at Jul 23 2008, 03:23:44 PM MDT 3 Comments

Talks for the Colorado Software Summit

I'm looking forward to another great year at the Colorado Software Summer in October. I submitted a couple abstracts back in April and have recently been granted the opportunity to change one.

The reason for the change is Yan Pujante (founder at LinkedIn) is going to do my talk on Building LinkedIn's Next Generation Architecture with OSGi and Spring. Since he's been very integral in writing the existing codebase, as well as the move to OSGi, it seemed more appropriate for him to do this talk. I'd like to keep my talk on Appcelerator, but I'm having a hard time deciding between four other options.

If you're planning on attending CSS this year, let me know which one you'd like to see most.

I could see changing the first option to Spring Web specifically. I could also see adding Rails and Grails to the 3rd choice. The 4th one is a lofty goal as the project has just begun. If we succeed, it could be a great talk.

Posted in Java at May 29 2008, 03:40:13 PM MDT 6 Comments

AppFuse Light 1.8.2 Released

AppFuse Light 1.8.2 is a bug fixes release that includes upgrades for Spring, Spring Security, Hibernate, Wicket, Tapestry and many others. In addition, Spring bean definitions were replaced with annotations (@Repository, @Service and @Controller). See the Release Notes for more information on what's changed since the last release.

AppFuse Light now offers 60 possible combinations for download:

  • Web Frameworks: JSF (MyFaces), Spring MVC (with Ajax, Acegi Security, JSP, FreeMarker or Velocity), Stripes, Struts 1.x, Struts 2.x, Tapestry, WebWork, Wicket
  • Persistence Frameworks: Hibernate, iBATIS, JDO (JPOX), OJB, Spring JDBC

AppFuse Light Screenshot - click on the box at the bottom right of AL to activate StyleSheet Switcher

If you have any questions about this release, please subscribe to the AppFuse user mailing list by sending a blank e-mail to [email protected]. You can also post questions in a forum-like fashion using Nabble: http://appfuse.org/forum/user.

Posted in Java at May 11 2008, 10:16:17 PM MDT Add a Comment

Apache 2 on OS X: Configuring mod_proxy and SSL

I recently had to setup Apache as a front-end web server for multiple backend servlet containers. The backend containers serve up different web applications, and the Apache front-end unites them from a hostname and port standpoint. The following instructions describe how to configure Apache 2 on Mac OS X to proxy requests to Tomcat or Jetty running on localhost:8080. It also shows how to enable SSL on Apache and force it for certain URLs in your Java web application.

Apache comes pre-installed on OS X, so you should be able to start it by enabling "Web Sharing" in System Preferences > Sharing.

$APACHE_HOME on Leopard is /etc/apache2. On Tiger, it's /etc/httpd. If you've upgraded Tiger to Leopard, it's likely you'll have both directories so make sure you're modifying the right one. I lost a few hours figuring this out, so hopefully this knowledge will appease some googler in the future.

Configuring mod_proxy

  1. Open $APACHE_HOME/httpd.conf and add the following on line 480 - at the very bottom, just before "Include /private/etc/apache2/other/*.conf".
    #
    # Proxy Server directives. 
    #
    <IfModule mod_proxy.c>
        ProxyRequests On
        ProxyPreserveHost On
    
        ProxyStatus On
        <Location /status>
            SetHandler server-status
    
            Order Deny,Allow
            Deny from all
            Allow from 127.0.0.1
        </Location>
    
        ProxyPass    /myapp    http://localhost:8080/myapp
    </IfModule>

    ProxyPreserveHost allows request.getServerName() and request.getServerPort() to work as if there is no proxy server in place. In other words, even though Tomcat is running on 8080, request.getServerPort() will return 80.

  2. The most important line is the last one as this is the dictates the location of your applications. Add more lines as you need to add more applications.
  3. If everything is configured correctly, you should be able to run sudo apachectl restart and navigate to http://localhost/status. If you receive a "forbidden" error, make sure your /etc/hosts has an entry mapping 127.0.0.1 to localhost (as one of the last entries), or change "Allow from 127.0.0.1" to "Allow from localhost". If you get a "Server not found" error, you can tail the error log at "/var/log/apache2/error_log".

One issue I've seen with mod_proxy is when a request comes in and the backend server is down. When this happens, Apache returns a 503 Service Temporarily Unavailable and it doesn't seem to go away after the backend server is restarted. It does resume proxying after a while, but I haven't determined what causes the proxy to come back to life. If you know a setting that forces mod_proxy to check for the backend server on every request, please let me know.

Configuring SSL

  1. Open $APACHE_HOME/httpd.conf and uncomment the following on line 470:
    Include /private/etc/apache2/extra/httpd-ssl.conf
  2. Open $APACHE_HOME/extra/httpd-ssl.conf and change line 78 to:
    ServerName localhost:443
  3. In httpd-ssl.conf, change line 99 to:
    SSLCertificateFile "/private/etc/apache2/ssl.key/server.crt"
  4. In httpd-ssl.conf, change line 107 to:
    SSLCertificateKeyFile "/private/etc/apache2/ssl.key/server.key"
  5. In httpd-ssl.conf, add the following after SSLEngine on to allow proxying via HTTPS:
    SSLProxyEngine on
  6. Follow the Using mod_ssl on Mac OS X tutorial. For "Common Name/Server Name", use "localhost". You can download the source for mod_ssl (which you need at one point during the tutorial) at http://www.modssl.org/source/.
  7. Run sudo apachectl restart and go to https://localhost. If you get a "Server not found" error, run sudo apachectl -t to verify the syntax of your config files or tail -f /var/log/apache2/error_log to verify there are no errors in the log files.

Forcing HTTPS for certain URLs
If you proxy requests from /myapp -> http://localhost:8080/myapp, request.isSecure() will return false. If you change it to /myapp -> https://localhost:8443/myapp, request.isSecure() will return true. I needed to figure out a way to have http://localhost/myapp go to http://localhost:8080/myapp and https://localhost/myapp to go http://localhost:8443/myapp. Even better, I wanted to configure things in a way so request.isSecure() returned the value based on the originally requested URL, not on the proxied URL. Configuration like the following would be ideal:

ProxyPass    http://*/myapp    http://*:8080/myapp
ProxyPass    https://*/myapp   https://*:8443/myapp

The solution I came up with is to standardize on secure URLs in my application. That is, use /secure/* as a prefix for all URLs that should be accessed via SSL. To follow this convention and force it, I added the following in my application's web.xml file:

<security-constraint>
  <web-resource-collection>
    <web-resource-name>Secure Area</web-resource-name>
    <url-pattern>/secure/*</url-pattern>
  </web-resource-collection>
  <user-data-constraint>
    <transport-guarantee>CONFIDENTIAL</transport-guarantee>
  </user-data-constraint>
</security-constraint>

Once this is in place, accessing http://localhost/myapp/secure/index.html will result in an error. Accessing it using https will succeed. Following this, you can change your ProxyPass rules to the following and all requests to /secure/* will be https; other requests will be sent to http. The order of the rules below is important.

ProxyPass    /myapp/secure   https://localhost:8443/myapp/secure
ProxyPass    /myapp          http://localhost:8080/myapp

If this isn't a good strategy for you, Tomcat has the ability to use a redirectPort (in server.xml) that auto-redirects from http to https when CONFIDENTIAL is used in web.xml. I'm not sure if this redirect will carry through values from a form post.

Posted in Open Source at Apr 24 2008, 10:58:03 AM MDT 8 Comments

The LinkedIn Journey Continues

As you might know, I've spent the last several months working for one of the coolest clients ever: LinkedIn. They hired me back in July 2007 and I was impressed on day one. I was originally hired to help them evaluate open source Java web frameworks and try to determine if moving from their proprietary one to an open source one would help improve developer productivity.

After looking at all the options, I recommended we look at Struts 2 and Spring MVC - primarily because they seemed to be the best frameworks for a LinkedIn-type of application. Another Engineer and I prototyped with Struts 2 for about 6 weeks and came up with a prototype that worked quite well. While our mission was successful, we found a couple issues with Struts 2 and standard JSP that might actually hurt developer productivity more than it helped.

Following this project, I worked on the New Homepage Team, which is now visible to everyone that logs onto LinkedIn. My role was minimal, but it was still a very fun project to work on. You know those widgets in the right panel? I did the initial UI and backend integration for those. All the business logic, Ajax/JavaScript, CSS, and optimization was done by other folks on the team. Shortly after this project went live in November, I started prototyping again with Spring MVC + JSP.

The reason I was asked to prototype with Spring MVC was because they were using Spring on the backend, Spring MVC in a couple other projects, and a new project was being kicked off that used Grails. Rather than add another framework (Struts 2) to the mix, they wanted to see if they could suppress any further framework proliferation.

After a month of prototyping with Spring MVC + JSP, my results weren't as good as Struts 2. With Struts 2, I was able to use OGNL to do all the things their current JSP implementation allows them to do (call methods with arguments, use statics in EL, etc.). With standard JSP, a lot of this wasn't possible. If it was - it required writing lots of tag libraries and made it more cumbersome for developers to do certain things. At the end of that project, I determined that using FreeMarker might solve these problems. I also determined that neither Struts 2 nor Spring MVC would solve the ultimate problem of developer productivity. Neither framework would allow developers to go from make-a-change-and-deploy, wait-3-minutes-to-see-change-in-browser to make-a-change, save and wait-15-seconds-to-see-change-in-browser.

I recommended that this be the ultimate goal - to get rid of the deployment cycle and to allow minimal turnaround when deploying modified classes. After that problem was solved, it's true that moving to an open source web framework would likely provide an easier-to-remember API. However, the problem with moving to a new web framework would be that everything used to construct the existing site would suddenly become legacy code.

In the end, we concluded that the best solution might be to enhance the existing framework to be more like the available open source options. This would allow existing applications to keep using their code -- and if we enhance properly -- new applications can use a simpler, less verbose API and a templating framework that's easier to understand. We can make LinkedIn's version of JSP more like standard JSP while allowing its powerful EL to remain. We can add support for JSP Tag Libraries and Tag Files.

One of the benefits of moving to an open source web framework is there's a community, documentation and books that describe the best (or most common) ways to solve problems with the framework. LinkedIn has this, but it's all in code and no one seems to have a high-level of confidence that the way that they did it is the "best" way. Developers communicate well, but all the knowledge is stuck in their heads and inboxes - there's no way for new developers to search this knowledge and figure it out on their own without asking somebody.

By adopting an open source web framework, it's possible to solve part of this problem, but I think it's still going to exist - where a few engineers know how to use the framework really well (for the specific application) and the rest don't. We determined that regardless of open source vs. proprietary framework, what was needed was a set of developers that acted as authorities on how to develop web applications at LinkedIn. A UI Frameworks Team if you will. This would be their only job and they would never get pulled from this to work on projects or complete tasks related to LinkedIn's products. Some developers mentioned that they'd been asking for this for years, and some folks had even been hired for this. However, the formulation of this group has never happened and it's obvious (now more than ever) that it'd be awesome to have them.

The UI Frameworks Team
At the end of 6 months, it seemed my work was done at LinkedIn. I liked the idea of a UI Frameworks Team and recommended they start it with the authors of the existing web framework. They agreed this was a good idea. A few days later, I was pulled into the CTO's office and he offered me the job. He offered me the challenge of building this team and told me I could do it remotely (from Denver) and hire my own people to help me with it. I gulped as I realized I'd just been offered the opportunity of a lifetime. I knew that while this might not be the best option for LinkedIn, it certainly was an excellent opportunity for me. I said I'd think about it.

In the meantime, I was given a project which you might've read about. They asked me to migrate a Rails application to Grails and try to determine if they really needed both frameworks. I spent 2 weeks coming up to speed on both and flew to Mountain View to deliver my conclusion. Here's an excerpt from an internal blog post I wrote.

As far as I know, Rails has been used at LinkedIn for well over 6 months and Grails has been used for a similar duration. Both projects that've used these technologies have enjoyed extreme success. Both projects have been fun for the developers working on them and both have improved the technologies/frameworks they're using.

Here's an interesting quote about the Rails application:

Another app you might want to look at is BumperSticker, our facebook app. Interestingly we heard through joyent that DHH (the creator of Rails) told them that BumperSticker is the biggest rails app in the world (in terms of page views) - we are closing in on 1 billion monthly page views and we have 1 million unique users per day (about 10 million installs on FB). It's a little trickier to setup in a dev environment since you need to be running on FB, but the code itself is pretty interesting since we've iterated on it a bunch of times and are making extensive use of third party libraries such as memcached.

This quote loosely translates to "We have some Rails Ninjas on staff and we've been quite successful in developing with it and making it scale".

Both platforms have allowed developers to iterate quickly and turbo-charge their productivity.

My Conclusion: Allow Both

Why?

If you have talented developers that can whip out kick-ass code with either platform, pay them and pay them well. Passion is the most important part of any job. If developers are passionate about the application they're developing and the language they're using (notice language is secondary) - they can do great things.

I know this probably isn't the answer you wanted to hear, but it's what I believe. I think both frameworks are very similar. I believe the knowledge you gain from learning one framework is transferable to the other. A lot of the things I learned about Rails worked with Grails. Ruby's syntax is similar to Groovy's.

There's a natural synergy between these two frameworks. The hard part is figuring out when to use which one.

The application that I was asked to port from Rails to Grails? The one that was launched last week - LinkedIn Mobile.

After doing this research, I stepped up to the plate and accepted the offer to start a UI Frameworks Team and recruited some kick-ass Java Developers I know to be the founding members. Last week, I flew out to Mountain View to do some kickoff meetings and start getting the infrastructure in place so we can document, support and release code like a well-oiled open source project. There's nothing saying we won't use an open source web framework as the underlying engine, but I think this should be an excellent chance to see the power of open source governance and development style in a corporate environment.

Director of Engineering, Core Experience
I should mention one last thing. If you're an experienced Java Developer/Architect with a passion and deep knowledge of UI development (JavaScript, CSS, HTML), we've got a Director of Engineering, Core Experience position with your name on it. I might even get to interview you if you apply for this job. Furthermore, whoever gets hired will likely work very closely with my team. What's not to like about that!? ;-)

Posted in Java at Mar 06 2008, 08:00:49 AM MST 19 Comments

Last Night's Selenium Users Meetup at Google

Last night, I attended the inaugural Selenium User Group meetup at Google's Campus in Mountain View. It was an excellent event, with many of the core committers on hand to present and answer questions. Each presenter had about 5 minutes to speak and we learned many things about the Selenium Project itself, what's coming in the future and how Google has standardized on Selenium as their integration testing tool of choice.

Patrick Lightbody started the meeting by going over a number of project statistics with pretty graphs and such. There were simply too many numbers to write down, so hopefully his slides will be published soon. I was pleased to see that Google did videotape the entire event, so it should be available online soon. I'll update this post when it it. Below are my notes from the event.

Jason Huggins, Test Engineer at Google
Selenium is a test automation framework. Some folks abuse it as a macro tool. There's two reasons Selenium became so popular: it was able to test Ajax before any other testing tool and it allows end-to-end workflow testing. Selenium works on any platform, with any browser and allows many, many languages. It's possible that other frameworks that are more focused are better. There are 4 Selenium products:

  • Selenium Core (TestRunner)
  • Selenium IDE (for Firefox)
  • Selenium Remote Control
  • Selenium Grid

Paul Hammant, Open Source Manager at Thoughtworks
Selenium 1.0 - beta this week. RC, Core, Grid and IDE together. 1.0 will be shipped in a few weeks. Compared to today, lots of bugs killed, documentation improved and a greatly improved Selenium IDE.

Selenium 1.1 will be shipped in a couple months. Selenium IDE will be enhanced to obey RC instruction ... becoming the best mode of operation when it ships.

Some experimental iPhone-Safari capability (dependent on SDK for iPhone).

Selenium 2.0 will hopefully be released this year. Roll in of WebDriver functionality and code. New model-based API. IE plugin and Safari plugin (not really a plugin, most likely uses AppleScript).

Philippe Hanrigou (http://ph7spot.com)
Testing is good! Selenium is awesome! However, end-to-end web testing is slow. It is and always will be slow. How do you solve this problem? You solve it the same way we've solved slow traffic in the past - by building more lanes. Rather than one browser testing everything, Selenium Grid allows multiple lanes and 20 browsers. Features include:

  • Faster Builds, Faster Feedback!
  • Easy Install and Everyday Use
  • No Need to Change Your Tests
  • Leverage Your Existing Computing Infrastructure

One of the best parts about Selenium Grid is you can download and have it running in 10 minutes or less. Selenium Grid comes out-of-the-box with Amazon EC2 support.

Jennifer Bevan, Lead from Selenium Farm Project at Google
As of Friday, Google has over 50 teams running over 51K tests per day on internal Selenium Farm. 96% of these tests are handled by Selenium RC and the Farm machines correctly. The other 4% are partly due to RC bugs, partly to test errors, but isolating the cause can be difficult. Selenium has been adopted as the primary technology for functional testing of web applications within Google. That's the good news.

The bad news is Google is pushing the limits of Selenium. Using Selenium (RC + Core) at this scale exposed certain issues not originally anticipated as high-impact. IE/XPath slowness has a high impaction given that can only run one test at a time. Tests can cause many conditions from which RC cannot easily or automatically recover (for example, tests that don't call stop() in every exit path). Unexpected browser dialogs, popups, etc. eventually cause timeout exceptions.

Googlers expect that RC will work for the most part, but they want it to be more reliable, with better performance. So they have:

  1. Created utility methods to improve performance when examinging large tables, overlaying domain-specific languages, etc.
  2. Deployed retry policies based on failure reason.

Looking to the future - Google has not yet reached their expected usage of Selenium RC. Some projects cannot use the Farm until RC supports session-level configuration (not server-level). Many just want RC to be more reliable. So Google will:

  1. Continue to contribute to RC, Core and to user-created helper libraries.
  2. Keep doing so until all failed tests are not Selenium's fault.

Dave Astels, Google (Driving Selenium with RSpec)
Using RSpec, you can create a very easy-to-read Story with Scenarios that can be read (and likely written) by practically anyone. Dave then uses a small script to load up the stories and run them in Selenium. When he runs the script, the scenario is spit out and test pass/fail information. Learn more at rspec.info.

Alex Chaffee, Mad Scientist at Pivotal Labs (The Selenium/Ruby Project that Must Not Be Named)
What is Polonium? It's also known as Selenium RC Fu or Selenium On Rails 2 or Funkytown. It has simple extensions to Selenium RC:

  • wait_for
  • element assertions
  • launching/managing servers locally

Blackbox testing you're sitting out of the box and send in stuff. In whitebox testing, you get to open up the box and look at stuff. With Selenium, you can do Graybox testing, where you are doing blackbox testing (against the UI) and querying your database (or other resources) at the same time.

Dan Faulich, Sr. QA Engineer at Redfin Corporation (How Not to Run a Successful Open Source Project)
The first thing you don't want to do is support everything. The second thing you don't want to do is write your project in JavaScript. While it's great that almost anyone can hack on it, running in a sandbox sucks. Don't use a language that's bound by other people's security restrictions. Don't roll your own multi-language remoting. It's written using XML + XSLT and its such a pain in the ass to maintain that Dan is the only one that fixes bugs.

Shinya Kasatani, Developer of Selenium IDE
Selenium IDE is a Firefox extension that can record and play back tests in your browser. It can translate the recorded tests to many languages.

Selenium IDE 1.0 adds support for TestSuites. Another new feature is better recording features - it detects when the DOM is modified. Shinya has a demo where he uses the new IDE to test the Dojo Dijit Theme Test Page. Apparently, this doesn't work in the current version.

The Goal of Selenium IDE is to get more people interested in test automation of web applications and to help their projects to be successful.

Haw-bin Chai, Developer at CommerceHub
XPath is a powerful selection took, but it'd be great if we could use something like "article 5" instead of the cryptic //table[5]/tbody/... syntax.

Why UI-Element? Traditional locations can be ugly and they don't convey purpose. UI-Element is a Selenium Core extension and has Selenium IDE integration. It's written in 100% JavaScript. Examples:

ui=frontPage::topStoriesCountry()
ui=listingPages::article(index=5)
ui=listingPages::articleSource(articleIndex=1)

The UI Map is in JavaScript shorthand. It contains logic to map ui locators to traditional locations. Each UI element implements getLocator(), then you add a page set and add an element - all in JSON Format.

Simon Stewart on Web Driver
What on earth is Web Driver? One of the main problems with Selenium is it's written in JavaScript and it's too easy to hack. WebDriver is an idealized browser which allows you to do browser things like call get(URL), findElement(By.xpath()) and getTitle(). WebDriver is similar to Selenium RC, but it's not written using JavaScript. It's written in the native languages for each browser, which allows you to break out of the JavaScript Jail. The IE Driver is written in COM (C++). The Firefox Driver is written as a Firefox extension. Safari uses Apple events.

Soon there won't be a WebDriver project ... because it will be part of Selenium!

WebDriver likely won't be part of the core until Selenium 2.0 later this year. One of the nice things about WebDriver is you can implement different browsers. Out-of-the-box, it will support all the major browsers, as well as HtmlUnit with JavaScript turned off.

I had a great time learning more about Selenium and how most of its problems will be solved in the near future. The beers afterwards weren't so bad either. ;-)

Update: Videos of this event have been posted.

Posted in Open Source at Feb 26 2008, 03:51:56 PM MST 10 Comments

Added a Tag Cloud

I added a tag cloud to this site tonight. Thanks to Rich Sharple's Hacking Roller : Tag Clouds, it was pretty easy. It's currently located in the bottom-right corner. Here's a glance at this site's most popular tags:

acegi appfuse denver grails gwt hibernate ibatis java jsf maven maven2 myfaces rails roller skiing spring springmvc stripes struts struts2 tapestry tomcat travel webframeworks wicket

Enjoy!

Posted in Roller at Feb 12 2008, 10:04:07 PM MST 4 Comments

YUI Grid CSS and Rails Performance

From Stephen O'Grady, I learned a couple interesting tidbits yesterday.

The first is Jeremy Zawodny talking about Yahoo's new Grid Builder in YUI Grid CSS and Grid Builder Kick Ass! The last time I looked at YUI Grid CSS (that's a mouthful) was almost 2 years ago, when it first came out. It's obvious that this library is better supported than Mike Stenhouse's CSS Framework. Maybe it's time to switch in AppFuse? Anyone know of themes available for Grid CSS?

The second item is Charlie Savage's entry titled Must Read Rails Performance Article:

Using a patched version of ruby and ruby-prof, Alex was able to more than double performance (with hints of more to come) and reduced memory consumption by 75%, or 750MB (yes - that is Megabytes). Alex does a wonderful job of documenting his approach with a series of blog posts here and here.

This reminds me of Don Brown's recent work on Maven. This is how open source is supposed to work - instead of complaining about the problems, fix them. In both Rails' and Maven 2's cases - it's somewhat surprising these issues weren't fixed earlier. Kudos to Alex Dymo and Don Brown for stepping up to the plate. Well done gents.

Posted in The Web at Feb 09 2008, 08:14:18 AM MST 2 Comments