Solving WYSIWYG issues

Lately I have been solving some WYSIWYG editor issues at work. We are using CKEditor in our system and there were several issues we wanted to solve.

1. Content written in the editor should be valid XHTML markup
2. Users should not be able to input any malicious code in our system such as JavaScript or CSS properties like position: absolute
3. Content pasted in the editor contains <br /> elements as line breaks whereas we would want each line to be wrapper inside <div> element
4. When pasting simple data into the editor we noticed <div> elements started to get nested
5. We wanted to modify the way how CKEditor automatically indents the source code

First issue is partly solved by CKEditor itself. It creates valid XHTML, but we didn't want to rely just on client based implementation. To be on the safe side and to solve second issue we ended up using HTML Purifier to clean data from any malicious code and make sure that the code is valid XHTML. We have noticed that HTML Purifier provides great flexibility in terms of how it can be configured and it has been just the right tool for us to clean data inserted by user. For example, the default setup didn't allow user to embed Youtube videos, but we could specifically allow <iframe> elements where source would point to Youtube or Vimeo. Any other iframe src attribute content would be automatically removed.

CKEditor paste issues were bit tricky ones to be solved. CKEditor contains internal logic that single line breaks are replaced with <br /> tags and two line breaks are replaced with enterMode in case enterMode is either p or div. Once we got around this issue by doing custom paste event handling we noticed that div elements were nested in such cases where they shouldn't have been. The complete code how I solved issues three and four is available at StackOverflow.

Finally issue number five was an easy one to fix. CKEditor Developer Guide provides good documentation how to manipulate CKEditor's output formatting and we tweaked it to fit our preferences.

Zend Framework

As I wrote yesterday, today I gave a lecture at JAMK about PHP application architecture and Zend Framework. Last two Tuesdays were more theory-based, but today we concentrated more on actually doing something. Therefore I don't have as many slides available in the Zend Framework set as there are in Modern Web Technologies.

The slides start by introducing some common problems which I've encountered while doing PHP application development. This was followed by some useful practices and design patterns for solving those issues. After problems and design patterns are out of the way, there are few slides about Zend Framework, what it is, why it makes sense to use it and some basic principles how Zend Framework based application works.

Rest of the time we concentrated on doing Zend Framework 1 Getting Started tutorial. Because of some security policy issues and problems with virtual environments some students didn't have a complete development environment available and we couldn't make Apache configurations for everyone. That's why going through the tutorial took a while, but finally we were able to get the demo application up and running for all students.

As with Modern Web Technologies, I decided to share the slides via SlideShare.

Updated Modern Web Technologies Slides

About 8 months ago I wrote about my lectures at JAMK. I got good feedback from this JavaScript, HTML 5 and CSS 3 set and was asked to do the same two lecture set again.

Before giving those lectures I revised and updated the slides. Here are the major changes I made to the slides.

• JavaScript singleton pattern usage is now fixed to use Douglas Crockford's module pattern.
• Section about web sockets is updated.
• Some examples are added, such as the basic HTML 5 doctype example page.
• JavaScript has now few slides about debugging which was placed just before introducing jQuery.

Tomorrow I will also give a lecture at JAMK about PHP application architecture and Zend Framework. I'll update those materials to SlideShare too, but first thing's first - here are the updated Modern Web Technologies slides.

Empowering people

On 27th of May I was privileged to attend second time for lecture by Wolfgang Steffens. This time he talked to us about lean, self organized teams and cost of delay.

Again there were a lot of good points and interesting topics in Wolfgang's lecture, but what probably hit me the most was the topic of victim versus empowered. Generally this applies to everything and can have a major impact of person's life. It boils down to this question: in case of some issue occurs, do you tend to be a victim or are you empowered and willing to do something about it?

Being victim is easy as you can blame external entities, there wasn't enough time, money or knowledge, I didn't have the power to make that decision, specifications were incomplete so I couldn't complete my work and so on. Although all of these can be true, empowered person would start to wonder what can I do about this. If the specifications are incomplete, maybe I could ask the other team to complete this by tomorrow. If we don't have enough money to implement all wanted features we will try to implement as many as we can as well as we can. Empowered person always thinks there is something I can do.

Being empowered is extremely important for productivity. But what can you do in order to empower the people around you, what does it require to be empowered? Few major things I wrote down from Wolfgang's session were ownership over what you do, being committed (I choose to ... because) versus being complied (I have to) and having meaning (clear vision, feeling of being part of something bigger).

Wolfgang said it well: "people want to be the best they can be". Of course there are exceptions, but generally this applies to everyone, I believe it is part of most human's nature to try to be the best they can be. At least I get satisfaction when I know I've done a good job. Give responsibility, let people make mistakes, let them learn and let them earn trust, let them be the best they can be and you will surely empower people in your organization.

Focus on the Product

One of the things I've picked up from application lifecycle management course that has had maybe the most influence in my daily work was when the following product lifecycle management principle was introduced to us.

"PLM puts the focus on the product"

Summarized this meant that in PLM both customer and product are important, but product comes before customer. In Humap Software I am constantly involved in service business and in service model this is not such a great principle as is. But I noticed this made me to think about the service paradigm.

Customer rarely has high level expertise about the field of technology in which we are creating the services them for. Because of that it is also unlikely that the customer can create exact specifications about what they want. Or actually customers can define what they want, but because we have the technological expertise, we can come up with more sophisticated solutions which customer might not even consider in the first place. What customers can very well do is to define what kind of problems they have. Our job is to analyze those problems and create as good solutions as we can.

I know that was bit provocative. Usually customers have good ideas and they have more or less good vision about what they want. This just got me thinking that we should always pursue towards the most excellent outcome and be brave enough to question the customers' views when we see a better solution.

Modern Web Technologies

As part of my studies I gave two lectures at JAMK about web technologies. I named this set as Modern Web Technologies and it consists of JavaScript, HTML5 and CSS3.

The slides aren't perfect and those topics are massive so naturally single slide set cannot contain everything there is to know about these three big ones. These slides are more like a summary of good techniques and practices I've encountered while doing web software development.

I noticed some flaws or inconsistencies after I published these slides, but didn't modify the slides any further. For example, there are two different examples of JavaScript singleton pattern. The first one is not as good as it relies upon placing anonymous function into variable whereas latter version is one recommended by Douglas Crockford (check out module pattern) and it uses object literal. I haven't used that version for that long, but it seems very logical and JSLint doesn't nag about it so I will use that version in the future.

Here goes, hope you like it :)

Another Look at Lean

On Saturday 11th of February I was attending to Application Lifecycle Management course at JAMK. There Heikki-Pekka Noronen was giving a lecture titled as "A Lean Perpective". The lecture gave me new ideas about lean.

I haven't investigated lean principles very deeply, but before the lecture I had quite solid idea about what lean is roughly about. Especially the "eliminate waste" was a familiar concept to me, but after the lecture I saw it in somewhat new light. I had become skeptic towards my previous impression of waste.

In HP's slides it was said that "waste is everything that does not add value" which is in my opinion a great way to summarize the definition. What really hit me were the things listed after this definition.

• Partially done work (such as defects, untested code, unfinished or unused documentation..)
• Slow internal communication
• Unclear requirements (they truly are partially done, are they not?)
• Queues, in all of their form

I'm unlikely the only software developer in the world who has been in such situation where stakeholders are asking what would be the fastest and cheapest way to implement some feature. I have thought that it's lean to think about some "duck tape quick-fix" in order to do something quickly as possible. But then again if the feature would be done properly with sustainable architecture, would it add value? First it was easy to think about maintainability, stability and other technical aspects and why it would always add value to go for proper architecture. Instead of always going for sophisticated solution, another kind of approach has had positive effects on our projects.

Value of proper architecture versus quickly implemented duck tape fix has usually a strong correlation between how temporary the outcome of the project is. This isn't always the case, but in our software development we have noticed this quite often being true.

If some web based application or environment is used only for short duration, it has been perfectly fine to patch, for example, some ugly user interface issues with bubble gum. It doesn't matter if the underlying core will eventually change and thus our quick-fix would then break because it's dependent of that core functionality - the environment is already deactive and has no usage. This is also the case if the outcome of the project is used only once and has no value for other projects. The shorter lifespan the outcome has, more wild and unstable implementations can be introduced without having to worry about long term support and stability.

If we are creating long term environments, products or applications, decision to patch something quickly would lead to unstable environment, more errors, more maintenance and unhappy customers when things fall apart. Also if we would create something that will probably be used in other projects too, it makes sense to invest more time to create proper architecture so that the next time the same outcome is used, it will work without hiccups.

I guess the most important message in the lecture for me was that it isn't necessarily against lean principles to test code thoroughly, write extensive documentation and design proper architectures. It's just the matter of what creates value and what does not.

This blog post was written from software developer's technical point of view. If you want to read about lean from more communicational and social point of view I recommend you to take a look at this blog post by Esko Kilpi.