Sunday, May 31, 2009
RightJS Updates
There was some updates on the RightJS project. It moved to it's own github account, IE6 benchmarks were added and I'm working on some basic visual effects library for the framework. It does lots of fancy stuff and weight just 5k extra. Kinda sweet.
Tuesday, May 26, 2009
RightJS Kicks The Butts
RightJS, on the start was real fast on the WebKit browsers and just above average on other browsers. The difference is that on WebKit browsers it was using the native css-selectors. But after an optimization session on the RightJS manual css-selectors, now we can proudly say, that RightJS kicks all the other frameworks on almost any browser and any conditions.
Check it out on the page RightJS Benchmarks, there are tests for all the modern browsers, including IE and Opera. There's no test results for IE6 yet, because it has some memory leaking issues which were not fixed yet and slows the browser down. But rest of the results looks cool
Check it out on the page RightJS Benchmarks, there are tests for all the modern browsers, including IE and Opera. There's no test results for IE6 yet, because it has some memory leaking issues which were not fixed yet and slows the browser down. But rest of the results looks cool
Wednesday, May 20, 2009
Meet RightJS
I would not consider it like an official start, but say we are rolling out and so I started the official site for my RightJS prject. Right here.
http://rightjs.org
http://rightjs.org
Thursday, May 14, 2009
Being Pragmatic about Agility
There is a book appeared recently called "Pragmatic Career" and there was a sentence in its annotation saying "when I started to look at my life throw the glasses of agility I started to see agile patterns just everywhere". Ok, that probably not the exact quote but the point is that some people getting the agility too far. They start to worship it almost as a religion and sure see its deeds just everywhere.
Don't get me wrong I'm not against agility and this is not another crapy article a la "agility sucks, I hate it". Nope, agile approach is a wonderful tool and I use it every day and pretty much happy with that. My point is that the agile approach is just a tool, you should use it wisely and be critical about it.
Agile approach works pretty well if you are an experienced developer, a ninja who knows how to give a good punch from almost any position. You don't plan too much, be flexible and if the things go a wrong way, you just adjust. It reduces the entry level, gives you ability to try this and that and see how is it going, etc., etc. You take all the advantages of the technique.
But when you are young, have a lack of experience and good habits, it might lead you to a wrong path. Because of it nature, people quite often start practicing the "shoot first think later" approach. They write crap and hope they will fix it later, don't write tests and documentation. They think that they are agile because they produce a lot of code and kinda buggy features which they gonna make better later. But in reality they go in circles over and over, and eventually spent an ugly amount of time.
Agile approach is not about creating crap now and make it better later, it's not about skip all the things you are too lazy to do or just don't know how to do. As the matter of fact, the original "Pragmatic Programmers" book in one of its tenants says directly opposite "Don't live with broken windows". More of that, any normal professional in any area will tell you the main rule of being effective "Do the things once and only once". If you need to get back and fix your solutions, you are just killing time.
Agility is all about flexibility and rapidness. It is a contradiction to the old fashioned heavy planning approach, a tool which lets avoid painful situations when you at the finish line and realize that you have not what you needed. With agile approach you do small steps, but it doesn't cancel the idea that you should do your steps right. You do small steps but each step should be done in a good way. If you rush to the end target, skipping steps and taking all the possible shortcuts, move by an unpredictable trajectory, at the end you will have something as much painful as if you was sticking to some wrong plan.
And the problem actually, the problem is in ourselves, it is in our brains, in the way it works. The mother nature designs the things the way they were working in the most effective way, consuming as less energy as possible, that's the matter of surviving, and our brains are not an exception. Instead of careful thinking, we tend to jump to conclusions based on our experience, on the things we believe. That's kind of solutions caching mechanism. And the agile approach fits it like a glove, you just make rapid decisions based on current situation and your guts and move forward.
The problem is that if you have right solutions in your cache/experience, you are good, but if you don't you'll go through all the problems and become one big pain in the butt, for yourself, for your colleagues and eventually for your customer.
And here we come to the sake of "evil" old planning.
Planning is getting evil almost the same way as anything else getting evil, including agile approach. When you overuse it. The sake of planning is that it lets you make the reality check, think critically, review your experience cache. You write some simple roadmap and ask yourself a question "How do I know what I know?". It lets you filter out problematic cases, make you aware about problems before you meet them. That's the way to make your brain actually work, not just return some first thing out of the cache.
The bottom line.
I think you've got the idea. Sometimes you should ask yourself what are you actually practicing when you are practicing an agile development? Don't you feel like going circles, getting back and fix the things all the time? How do you know about the decisions you made? Don't you call something useless just because you too lazy or just don't really know how to use it? If you have any hesitations, it's okay to stop, sit down and think about the things for 20 minutes, do some reality check, maybe even take a good old pencil and piece of paper and write down some short plan.
This will make you actually think about the things, which will make you better, and better you will produce a better work.
Don't get me wrong I'm not against agility and this is not another crapy article a la "agility sucks, I hate it". Nope, agile approach is a wonderful tool and I use it every day and pretty much happy with that. My point is that the agile approach is just a tool, you should use it wisely and be critical about it.
Agile approach works pretty well if you are an experienced developer, a ninja who knows how to give a good punch from almost any position. You don't plan too much, be flexible and if the things go a wrong way, you just adjust. It reduces the entry level, gives you ability to try this and that and see how is it going, etc., etc. You take all the advantages of the technique.
But when you are young, have a lack of experience and good habits, it might lead you to a wrong path. Because of it nature, people quite often start practicing the "shoot first think later" approach. They write crap and hope they will fix it later, don't write tests and documentation. They think that they are agile because they produce a lot of code and kinda buggy features which they gonna make better later. But in reality they go in circles over and over, and eventually spent an ugly amount of time.
Agile approach is not about creating crap now and make it better later, it's not about skip all the things you are too lazy to do or just don't know how to do. As the matter of fact, the original "Pragmatic Programmers" book in one of its tenants says directly opposite "Don't live with broken windows". More of that, any normal professional in any area will tell you the main rule of being effective "Do the things once and only once". If you need to get back and fix your solutions, you are just killing time.
Agility is all about flexibility and rapidness. It is a contradiction to the old fashioned heavy planning approach, a tool which lets avoid painful situations when you at the finish line and realize that you have not what you needed. With agile approach you do small steps, but it doesn't cancel the idea that you should do your steps right. You do small steps but each step should be done in a good way. If you rush to the end target, skipping steps and taking all the possible shortcuts, move by an unpredictable trajectory, at the end you will have something as much painful as if you was sticking to some wrong plan.
And the problem actually, the problem is in ourselves, it is in our brains, in the way it works. The mother nature designs the things the way they were working in the most effective way, consuming as less energy as possible, that's the matter of surviving, and our brains are not an exception. Instead of careful thinking, we tend to jump to conclusions based on our experience, on the things we believe. That's kind of solutions caching mechanism. And the agile approach fits it like a glove, you just make rapid decisions based on current situation and your guts and move forward.
The problem is that if you have right solutions in your cache/experience, you are good, but if you don't you'll go through all the problems and become one big pain in the butt, for yourself, for your colleagues and eventually for your customer.
And here we come to the sake of "evil" old planning.
Planning is getting evil almost the same way as anything else getting evil, including agile approach. When you overuse it. The sake of planning is that it lets you make the reality check, think critically, review your experience cache. You write some simple roadmap and ask yourself a question "How do I know what I know?". It lets you filter out problematic cases, make you aware about problems before you meet them. That's the way to make your brain actually work, not just return some first thing out of the cache.
The bottom line.
I think you've got the idea. Sometimes you should ask yourself what are you actually practicing when you are practicing an agile development? Don't you feel like going circles, getting back and fix the things all the time? How do you know about the decisions you made? Don't you call something useless just because you too lazy or just don't really know how to use it? If you have any hesitations, it's okay to stop, sit down and think about the things for 20 minutes, do some reality check, maybe even take a good old pencil and piece of paper and write down some short plan.
This will make you actually think about the things, which will make you better, and better you will produce a better work.
Monday, May 11, 2009
Who's Your Daddy?
There's a pet project of mine called "RightJS". Yup as you can see it from the name it's yet another javascript framework. Well kinda. At the moment it provides most of the useful features of Prototype, salted with some features from dojo and spiced with features from jQuery and MooTools. It weights just 28k and wether you know passes the taskspeed test just like that.
There's the test source http://github.com/MadRabbit/taskspeed .
Okay, okay. Don't hold your breath. It's just in WebKit. In FF it's faster than Prototype at about 20% and still slightly faster than jQuery. In Opera it about same speed as jQuery and a little bit slower than Prototype. In IE... Well... Who uses that obsolete browser anyway?
PS: I would not believe tests result for jQuery on the benchmark, case when Prototype and RightJS were honestly loaded with elements building, updating etc. But as jQuery does not have this functionality, tests for it just feed the results with strings of already created html. Kinda cheating, you know.
There's the test source http://github.com/MadRabbit/taskspeed .
Okay, okay. Don't hold your breath. It's just in WebKit. In FF it's faster than Prototype at about 20% and still slightly faster than jQuery. In Opera it about same speed as jQuery and a little bit slower than Prototype. In IE... Well... Who uses that obsolete browser anyway?
PS: I would not believe tests result for jQuery on the benchmark, case when Prototype and RightJS were honestly loaded with elements building, updating etc. But as jQuery does not have this functionality, tests for it just feed the results with strings of already created html. Kinda cheating, you know.
Monday, April 27, 2009
One Image Round Corners
I'd like to share with you some fancy idea how you make easily maintainable css-based round corners on your pages. It's quite a common feature those days and if you don't know how to do that it might be quite a headache.
The Idea
The idea is pretty simple. You create an image which contains all four of your box corners. Usually it's just a small circle or a ring. Something like that.
Then you create an html-tags structure, like this.
It is not necessary to have the middle div.data, but it will provide you move flexibility for css-alterations in future, so you'd better have it in there.
And eventually you write some piece of css-code.
The stylesheet uses the images shading technique and displays a quoter of the image for each corner, so the pixel sizes in style definition should be equal to a quoter of your corners image. And the box by itself has some nice padding of the same size, so the box was looking visually correct and fit the corners.
This is pretty much it.
Why Do It Like That?
Well. There are several reasons.
a) It gets down the number of server requests to the server. For such tiny images, the actual loading time is the time of request and response to the server. So making it one image instead of four you make your page loading faster and don't bother your server.
b) When you have one image, you don't need to deal with each corner separately, you can unify and compact the styles, and then if you need, you can replace all the corners really easy but replacing just one image. It provides you really good flexibility in terms of css-based design. Take a look in here One Image Corners Example, I've created some demo for you. See how it's easy alterable for various cases. You just change the background color and image url and have another box ready to go.
c) With such approach in most cases your boxes will be still looking consistent if there is some problem with the image loading. User doesn't see unprofessionally looking cases when you have four separated images and one of them was lost or just when they are getting loading one by one. With one image the user will have all the corners at once, and if the image was lost, he will still see appropriate looking box on the page.
PS: If you need transparent backgrounds at the outer angles of the corners, you can have them on the same exact tags structure, but you will need some additional mambo jumbo in your stylesheet, which I didn't intend to cover in the article. But in 99.9% of good modern designs you won't need that anyway.
PPS: This certain css example does not work correctly on IE6, although it is entirely possible to make it working there, just I don't want to spend my free time on that zombie. If you need to support it you just put some additional adjustments into you css file with IE patches.
The Idea
The idea is pretty simple. You create an image which contains all four of your box corners. Usually it's just a small circle or a ring. Something like that.
Then you create an html-tags structure, like this.
<div class="box">
<div class="corners top"><div class="left"></div><div class="right"></div></div>
<div class="data">
Your text goes here
</div>
<div class="corners bottom"><div class="left"></div><div class="right"></div></div>
</div>
It is not necessary to have the middle div.data, but it will provide you move flexibility for css-alterations in future, so you'd better have it in there.
And eventually you write some piece of css-code.
div.box {
padding: 8px;
}
div.box div.corners div {
height: 8px;
width: 8px;
position: relative;
float: left;
margin-top: -8px;
margin-left: -8px;
margin-right: -8px;
background: url('corners_image.gif') no-repeat 0 0;
}
div.box div.bottom div { margin-top: 0; }
div.box div.corners div.right {
float: right;
background-position: 100% 100%;
}
div.box div.top div.right { background-position: 100% 0; }
div.box div.bottom div.left { background-position: 0 100%; }
The stylesheet uses the images shading technique and displays a quoter of the image for each corner, so the pixel sizes in style definition should be equal to a quoter of your corners image. And the box by itself has some nice padding of the same size, so the box was looking visually correct and fit the corners.
This is pretty much it.
Why Do It Like That?
Well. There are several reasons.
a) It gets down the number of server requests to the server. For such tiny images, the actual loading time is the time of request and response to the server. So making it one image instead of four you make your page loading faster and don't bother your server.
b) When you have one image, you don't need to deal with each corner separately, you can unify and compact the styles, and then if you need, you can replace all the corners really easy but replacing just one image. It provides you really good flexibility in terms of css-based design. Take a look in here One Image Corners Example, I've created some demo for you. See how it's easy alterable for various cases. You just change the background color and image url and have another box ready to go.
c) With such approach in most cases your boxes will be still looking consistent if there is some problem with the image loading. User doesn't see unprofessionally looking cases when you have four separated images and one of them was lost or just when they are getting loading one by one. With one image the user will have all the corners at once, and if the image was lost, he will still see appropriate looking box on the page.
PS: If you need transparent backgrounds at the outer angles of the corners, you can have them on the same exact tags structure, but you will need some additional mambo jumbo in your stylesheet, which I didn't intend to cover in the article. But in 99.9% of good modern designs you won't need that anyway.
PPS: This certain css example does not work correctly on IE6, although it is entirely possible to make it working there, just I don't want to spend my free time on that zombie. If you need to support it you just put some additional adjustments into you css file with IE patches.
Sunday, April 5, 2009
FrontCompiler Updates
Finally I've found some time and implemented a new feature for the FrontCompiler project.
This feature compresses your javascript code by using the tokens dictionary mechanism and then create another javascript which will recompose your original javascript code on the users browser.
Reconstruction happens pretty quick, almost unnoticeable. And this gives you extra 20-40% of compression over the usual front-compiler compression, which as we all know is already better than the YUI compressor's.
Say the latest Prototype v1.6.0.3 was compressed from 138 kB to 59 kB. MooTools was compressed from 98k to 50k, etc.
You can grab the latest, already compressed files here http://stcamp.net/share/prototype/
Try it, it's just awesome!
This feature compresses your javascript code by using the tokens dictionary mechanism and then create another javascript which will recompose your original javascript code on the users browser.
Reconstruction happens pretty quick, almost unnoticeable. And this gives you extra 20-40% of compression over the usual front-compiler compression, which as we all know is already better than the YUI compressor's.
Say the latest Prototype v1.6.0.3 was compressed from 138 kB to 59 kB. MooTools was compressed from 98k to 50k, etc.
You can grab the latest, already compressed files here http://stcamp.net/share/prototype/
Try it, it's just awesome!
Subscribe to:
Posts (Atom)