Adding the includeClassIf Method to Ext.Element

I’ve created an includeClassIf method on Ext.Element with the following code:

Ext.override(Ext.Element,{
includeClassIf: function(cls,condition){
condition ? this.addClass(cls) : this.removeClass(cls)
}
});

There are few situations when Ext.Element.toggleClass is the best choice. In fact, just willy nilly toggling anything is risky because you’re assuming that whatever the current state, you want it to be the opposite. That’s messy in most cases.

Then there’s addClass and removeClass, but those are literal, so you must switch between the two using a conditional if you know the state you want to use.

What’s missing in the Ext.Element Class is a way to specify the css class and the state dynamically, when the desired state is known. So with the includeClassIf method, you can do the following:

var state = checkbox.checked;
Ext.get('some_div').includeClassIf('selected',state);

instead of:

var state = checkbox.checked;
if(state){
Ext.get('some_div').addClass('selected');
} else {
Ext.get('some_div').removeClass('selected');
}

Add comment October 1st, 2009 Author: wmeurer

FineTooth at AMIA

FineTooth will be at the AMIA 2006 Symposium for a poster presentation with the Fred Hutchinson Cancer Research Center. The presentation is on the use of our automated text extraction service to build a cancer tumor registry from pathology reports. The poster presentation is part of S13 Poster Session 1. If you are going to AMIA this year stop by and say hi. If you can’t make it here is a link to a PDF of the poster. Please note the real poster is 4 feet high and 8 feet wide, so the file is large.

Add comment November 8th, 2006 Author: ScottD

Job Openning at Finetooth

We are in the hunt for another UI developer for our contract management web application. If you are in the market or know someone who is, shoot them the job info. Here is a repost of the information from our corporate site:

Senior UI Developer

FineTooth is currently seeking a Senior UI Developer to join our team and contribute to the front end development of our web based, scalable, on demand applications. Working together with a small team of web and database developers in an agile environment, the Senior UI Developer will have the opportunity to develop and gain experience in a fun, fast-paced, and flexible environment.

Qualifications:

• 4+ years experience in UI development, preferably with scalable production web applications
• Strong experience with HTML, CSS, JavaScript and AJAX programming patterns
• Experience with PHP and XML
• Familiarity with graphic design and associated tools including Photoshop and Illustrator
• Good sense of usability in graphical UI design running on real time systems
• Ability to work both independently and as a member of a small team
• Desire to work in a fast-paced, fun, and flexible environment with great benefits, developing cutting edge technologies
• Undergraduate degree or equivalent years of industry work experience

Applicants are encouraged to provide examples of past UI development work or sample applications that demonstrate UI and software engineering skills.

For immediate consideration, please send a word doc resume to careers@finetooth.com with “Senior UI Developer” in the subject line.

Add comment November 6th, 2006 Author: ScottD

OpenAjax Alliance Meeting Update

Last week was the second face-to-face meeting of the OpenAjax Alliance membership, fresh on the heels of the AJAXWorld conference in Santa Clara, CA. The meeting was two-days long, with day one focused on a mix of show-and-tell, group breakout discussions, and objective proposals. Day two focussed on the future of Ajax and mobile development. The result is that the group has solidified plans to produce an event and markup scanner component for developers to help ensure framework and code compatibility as well as toolkit interoperability – i.e. say you want to use a MooTools Accordion and a Dojo Fisheye together somehow. That might actually be perverse, but anyhow you get the drift. California was beautiful and Sun has a great layout and cafeteria. The Chinese Steamed Fish was superb!

Add comment October 14th, 2006 Author: Lindsey Simon

Ad-Hoc teams for Agile Development

As a company that is working on implementing the Agile process to develop a product aimed in the enterprise space, I have been very interested by the series of posts from RedMonk’s Michael Cote called “Agile in the Enterprise”. His comments and the problems of implementing Agile with large teams got me thinking. He mentioned the practice of having “Scrum-of-Scrums”. He mentions that coordinating all those small teams and keeping everyone pointed in the same direction is difficult. I think one of the problems comes from the structure of teams in large software shops.

Traditionally teams are divided by areas that match up to the architecture of the technology. So you would have a “UI” team and a “Repository” team and an “API” team, etc. This kind of division creates silos of expertise and responsibility that are an anathema to the Agile process.

For one, this break up harms the open communication upon which Agile depends. The channels of communication between teams in a large company are not going to be as open and responsive as those within the smaller group. Teams are placed in different areas of the company, sometimes on different floors or buildings, or worst yet cities. If a developer from the UI team has a problem with some new feature that interacts with the reporting engine, how long is it going to take to get an answer/solution when the report engine team in located in a different building instead of the next room?

Also, new features rarely rest in a single part of a system. This forces the work of a story card to be divided among several teams with different priorities and team leads. The coordination for this division is supposed to take place during the Scrum-of-Scrums. But each group will prioritize its own work to meet its own deliverables. This could create delays and conflicts between groups.

Finally, I think the break up of expertise and responsibility amongst teams will harm the clean and refactoring of the system. In Agile you are supposed to constantly be refactoring to clean up cruft in the system and improve its implementation or design. But if you only have access to or knowledge of small segments of a larger system how confident are you on the repercussions of your changes? And if the one team spots a change to be made in another part of the system can they make the change or does it get scheduled for the next sprint?

Ad-Hoc Teams

An idea I was mulling over, and I don’t think it is probably unique, is to create teams in an ad-hoc fashion. At a large development shop there would be a pool of team leads and a pool of developers. At the start of a sprint teams would be formed based on the work to be preformed. Each group would contain the developers and expertise necessary to complete the story cards they were assigned. If the cards require 2 UI guys and 1 DBA, fine. If it requires only developers that know the repository engine, fine.

The processed use to form these groups at the start of a sprint can be as formal as the business requires. You could get all the leads in a room and have them divide the work and then chose which developers would be best for each team. You could also have a more democratic method of all the developers choosing there own teams as you go through the cards. You can try and have people rate which features they would like to work on in the next release and then try and best match those preferences. I think the method used depends a lot on the personalities of the people involved and how they interact. Results for each may vary and it is a process that I think would have to be tuned for the first couple of sprints. The only process I would avoid is the having the team leads pick people in a round robin type fashion. A little too much like the schoolyard playground. Too many painful memories for most programmers about being picked last every time for baseball even though you know you are better then Stevie. But I digress into my own childhood issues.

The important part is that you want people overtime to work with different teams and in different parts of the system. This will improve everyone’s knowledge of the system. It will also give everyone a chance to work with everyone else. I think overtime this will make the teams more productive and estimates more reliable.

These ad-hoc teams could also give a company the opportunity to try a lot of flex space solutions. Do the ad-hoc team members move every sprint to a new location? If so what kind of office space do they have? One war room or cubicle area per team? What kind of IT and building management issues can this cause? If you don’t relocate people for each sprint how do you create open communication channels for the new team? Also, would not moving people create pressure to put people that are already located together in the same team? This would scuttle the idea of having people move through teams. I know some companies that are very successful and have developers living in different cities but still work closely with each other. IM, email, Skype, and monitor sharing software may be the answer for this.

FineTooth currently has a small development team and we haven’t had to worry about these issues yet. But as we grow as a company the problem of keeping a fast, agile small company approach is on my mind. I would like to hear what other people are doing, or not doing and their experience. I would especially like to hear about people who have worked for companies that have transitioned from 5-10 developers to 20+.

Add comment March 17th, 2006 Author: ScottD