azizkhani.net

I know that I know nothing

Top 20 Web Frameworks for the JVM

clock November 25, 2012 14:53 by author Administrator

 



50 Tricks for Faster Web Applications

clock November 25, 2012 13:05 by author Administrator

Jatinder Mann, an Internet Explorer PM at Microsoft, held the session 50 performance tricks to make your HTML5 apps and sites faster at BUILD 2012, providing many tips for creating faster web applications.

The advice provided by Mann was organized around six principles outlined below.

1. Quickly Respond to Network Requests.

  • Avoid Redirections. 63% of the top 1,000 websites use redirections. They could increase the speed of their pages by 10% by not performing a redirect.
  • Avoid Meta-refresh. 14% of the world’s URLs use meta-refreshes.
  • Minimize server response time by using CDNs located as close as possible to the user
  • Maximize the usage of concurrent connections by downloading resources from different domains
  • Reuse connections. Don’t close the connection when responding to a request.
  • Make sure data served by partner sites is not delaying page load
  • Understand the network timing components –Redirect, Cache, DNS, Request, Response, etc. –. Use the Navigation Timing API on IE 9&10 to measure the time spent by the browser on each operation.

2. Minimize Bytes Downloaded. Minimize the amount of data downloaded when a web page is loaded. The average website downloads 777KB of data out of which 474KB being images, 128KB scripts, and 84KB Flash.

  • Request gzipped content
  • Keep resources locally in packages, such as the Package Resource Index generated for the Windows Store apps. That way they are readily available when necessary.
  • Cache dynamic resources in HTML5 App Cache. This cache downloads the resources only once avoiding multiple network trips. The cache automatically re-downloads resources when the version of the application changes.
  • Provide cacheable content whenever possible by using the “Expires” field in the response.
  • Use conditional requests by setting the If-Modified-Since field of the request. 
  • Cache data requests –HTTP, XML, JSON, etc. – because about 95-96% of the requests don’t change over the day. Although a reasonable idea, less than 1% of the websites cache the requests received.
  • Standardize file naming capitalization. While a server may recognize Icon.jpg as icon.jpg, they are different resources for the web platform, generating different network requests.

3. Efficiently Structure Markup. For IE use the latest markup standardization since it is the fastest. Earlier IE6-IE9 markup styles are recognized by IE 10 but they are not as fast as the latest one.

  • Use the HTTP header field “X-UA-Compatible: IE=EmulateIE7” instead of the HTML tag <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7"> to force IE run in a legacy mode that might be needed for certain business web applications. It’s faster that way.
  • Stylesheets should be linked at the top of the page inside the <head>, after the <title> in order to provide a smooth rendering.
  • Stylesheets should never be linked at the bottom of the page. The page may be flashing while loading.
  • Avoid “@import” for hierarchical styles because it synchronously blocks the creation of CSS data structures and screen painting.
  • Avoid embedded and inline styles because it forces the browser to make a context switch between the HTML and CSS parsers.
  • Only include the necessary styles. Avoid downloading and parsing style that won’t be used.
  • Link JavaScript only at the bottom of the page. This makes sure that the images, CSS, etc. are already loaded so the scripts can do they job without waiting on the resources, and avoiding context switching.
  • Do not link JavaScript in the head of the page. Use the “defer” attribute if some scripts must be loaded at the beginning.
  • Avoid inline JavaScript to avoid context switching.
  • Use the “async” attribute to load JavaScript to make the entire script loading and executing asynchronous.
  • Avoid duplicate code. 52% of the world’s web pages contain 100 lines or more of duplicate code such as linking a JavaScript file twice.
  • Standardize on one JS framework, be it jQuery, Dojo, Prototype.js, etc.. The browser won’t have to load multiple frameworks that provide basically the same functionality.
  • Don’t load scripts –FB, Twitter, etc. - just to be cool. They compete for resources.

4. Optimize Media Usage. Images are the most utilized resource, on average a website downloading 58 images.

  • Avoid downloading too many images, keeping their number to maximum 20-30 due to page load time.
  • Use image sprites to combine multiple images into one. This technique reduces the number of network connections, and the number of bytes downloaded and GPU cycles.
  • Create image sprites by hand because tools may leave large empty spaces leading to larger downloads and more GPU cycles.
  • Use PNG: best compromise between download size, decoding time, compatibility, and compression rate. JPEG may be used for photographs.
  • Use the native image resolution to avoid unnecessary bytes download and CPU processing for scaling.
  • Replace images with CSS3 gradients when possible.
  • Replace images with CSS3 border radius when possible.
  • Use CSS3 transforms to create move, rotate or skew effects.
  • Use Data URI for small single images. It saves an image download.
  • Avoid complex SVGs which require longer downloads and processing.
  • Specify an image preview when including an HTML5. The browser won’t have to download the entire video to figure out what the preview image should be.
  • Use HTML5 instead of Flash, Silverlight, or QuickTime. HTML5 is faster and the plug-in runtime takes system resources.
  • Proactively download rich media asynchronously and keep it in the app cache.

5. Write Fast JavaScript.

  • Use Integers when doing math operations in JavaScript, if possible. Floating point operations take much longer in JavaScript than their corresponding integer operations. Convert floating points into integers with Math.floor and Math.ceil, especially for computationally intensive operations.
  • Minify JavaScript code for smaller downloads and better runtime performance.
  • Initialize JS on demand. Load JS dynamically when needed.
  • Minimize DOM interactions by caching variable such as document, body, etc.
  • Use the built-in DOM code such as element.firstChild or node.nextSibling. They are highly optimized, better than what a third party library might provide.
  • Use querySelectorAll for accessing a large number of DOM elements.
  • Use .innerHTML to construct dynamic pages.
  • Batch markup changes.
  • Maintain a Small and Healthy DOM – maximum 1,000 elements.
  • JSON is faster than XML.
  • Use the browser’s JSON native methods.
  • Don’t abuse the usage of regular expressions.

6. Know What Your Application is Doing

  • Understand JavaScript timers: setTimeout and clearInterval. Don’t let timers run unless you use them for something. Also, combine timers.
  • Align timers to the display frame at 16.7 ms if the monitor refreshes at 60Hz.
  • Use requestAnimationFrame for animations to do graphics work in IE 10/Chrome/Firefox. It makes a call back when it is the time to paint, so there is no need for a timer.
  • Use the visibility API (document.hidden, Visibilityhange) to determine the visibility state of the application, and throttle down activity when the page is hidden. Saves CPU and battery life.

Mann recommended using Windows Performance Tools to measure the performance of web pages in IE and optimizing pages for less CPU time and increasing parallelism.

 



The Principles of Good Programming

clock November 23, 2012 13:56 by author Administrator

The principles of good programming are closely related to principles of good design and engineering. The following programming principles have helped me over the years become a better programmer, and I believe can help any developer become more efficient and to produce code which is easier to maintain and that has fewer defects.

DRY - Don’t repeat yourself. - Probably the single most fundamental tenet in programming is to avoid repetition. Many programming constructs exist solely for that purpose (e.g. loops, functions, classes, and more). As soon as you start repeating yourself (e.g. a long expression, a series of statements, same concept) create a new abstraction.
http://en.wikipedia.org/wiki/Don%27t_repeat_yourself

Abstraction Principle - Related to DRY is the abstraction principle “Each significant piece of functionality in a program should be implemented in just one place in the source code.”
http://en.wikipedia.org/wiki/Abstraction_principle_(programming)

KISS (Keep it simple, stupid!) - Simplicity (and avoiding complexity) should always be a key goal.
http://en.wikipedia.org/wiki/KISS_principle

Avoid Creating a YAGNI (You aren’t going to need it) - You should try not to add functionality until you need it.
http://en.wikipedia.org/wiki/YAGNI

Do the simplest thing that could possibly work - A good question to ask one’s self when programming is “What is the simplest thing that could possibly work?” This helps keep us on the path towards simplicity in the design.
http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.html

Don’t make me think - This is actually the title of a book by Steve Krug on web usability that is also relevant in programming. The point is that code should be easily read and understood with a minimum of effort required. If code requires too much thinking from an observer to understand, then it can probably stand to be simplified
http://www.sensible.com/dmmt.html

Open/Closed Principle - Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification. In other words, don't write classes that people can modify, write classes that people can extend.
http://en.wikipedia.org/wiki/Open_Closed_Principle

Write Code for the Maintainer - Almost any code that is worth writing is worth maintaining in the future, either by you or by someone else. The future you who has to maintain code often remembers as much of the code, as a complete stranger, so you might as well always write for someone else.
A memorable way to remember this is “Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.”
http://c2.com/cgi/wiki?CodeForTheMaintainer

Principle of least astonishment - The principle of least astonishment is usually referenced in regards to the user interface, but the same principle applies to written code. Code should surprise the reader as little as possible. The means following standard conventions, code should do what the comments and name suggest, and potentially surprising side effects should be avoided as much as possible.
http://en.wikipedia.org/wiki/Principle_of_least_astonishment

Single Responsibility Principle - A component of code (e.g. class or function) should perform a single well defined task.
http://en.wikipedia.org/wiki/Single_responsibility_principle

Minimize Coupling - Any section of code (code block, function, class, etc) should minimize the dependencies on other areas of code. This is achieved by using shared variables as little as possible. “Low coupling is often a sign of a well-structured computer system and a good design, and when combined with high cohesion, supports the general goals of high readability and maintainability”
http://en.wikipedia.org/wiki/Coupling_(computer_programming)

Maximize Cohesion - Code that has similar functionality should be found within the same component.
http://en.wikipedia.org/wiki/Cohesion_(computer_science)

Hide Implementation Details - Hiding implementation details allows change to the implementation of a code component while minimally affecting any other modules that use that component.
http://en.wikipedia.org/wiki/Information_Hiding

Law of Demeter - Code components should only communicate with their direct relations (e.g. classes that they inherit from, objects that they contain, objects passed by argument, etc.)
http://en.wikipedia.org/wiki/Law_of_Demeter

Avoid Premature Optimization - Don’t even think about optimization unless your code is working, but slower than you want. Only then should you start thinking about optimizing, and then only with the aid of empirical data.
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil" Knuth.
http://en.wikipedia.org/wiki/Program_optimization

Code Reuse is Good - Not very pithy, but as good a principle as any other. Reusing code improves code reliability and decrease development time.
http://en.wikipedia.org/wiki/Code_reuse

Separation of Concerns - Different areas of functionality should be managed by distinct and minimally overlapping modules of code.
http://en.wikipedia.org/wiki/Separation_of_concerns

ref:http://area.autodesk.com/blogs/chris/the_principle_of_good_programming



Introduction To Scrum

clock November 23, 2012 13:46 by author Administrator

This post is an introduction to Scrum, one of the Agile methods to drive software application implementation. Reading this post is a prerequisite to this post.

Concepts

  • Scrum projects deliver software application features iteratively.
  • Each iteration is called a sprint.
  • Scrum projects have 4 stages:
    • Planning – Definition of the vision, budget, and expectations. The first version of the product backlog should containing enough implementation items for the first sprint.
    • Staging – This is the first iteration where the requirements and product backlog created in the planning are refined.
    • Development – It is the set of sprints required to implement the project fully. It ends when the product backlog is empty.
    • Release – The final product is deployed, training is performed, documentation is finalized, etc… The release backlog can be used as the product backlog for the next release of the product.
  • There are 4 main roles in scrum projects: team member, product owner, stakeholders and scrum master:
    • A product owner is a customer representative acting as a single point of contact on the customer side.
    • A stakeholder is anyone having a vested interest in the project, providing information about requirements and participating to the decision process of features to be implemented.
    • A scrum master is a facilitator and single point of contact on the development team side. It is a support function, not a ‘controlling chief’ role. It is a mix between a team leader and a software engineering role, which does not include people management or profit & lost responsibilities.
    • A team member is a software engineer.
  • Scrum of scrum can be implemented when multiple scrum teams are working on the same large project. Scrum master and product representatives get together.
  • The product backlog is a list of features, use cases, enhancement, defect, etc… to be implemented in the project’s forthcoming sprints.
  • The release backlog is the list of features, uses cases, enhancement, defect, etc… which are postponed to the next version of the project (not next sprint).

 
Practice

  • Spring teams typically do not have more than 7 members.
  • A sprint duration is 30 days.
  • Scrum projects are client-driven. They select the features to be implemented.
  • Each sprint begins with two meetings:
    • The stakeholder meeting, with the scrum master and customer representative to re-prioritize the product backlog and update the release backlog.
    • The product owner and team meeting where tasks are created from the product backlog.
  • Each task must require between 4 and 16 hours of work. Bigger tasks must be subdivided into smaller tasks.
  • The scrum master and product owner check whether there are enough resources to support the efforts required to achieve the sprint and adjust the workload accordingly.
  • Team member pick their tasks and work on their implementations.
  • Each spring finishes with a presentation of implemented features to the stakeholders.
  • Every day, a stand-up meeting (15-20 mins) with the team members and eventually the product owner is organized in front of a white board. The following is discussed:
    • Which tasks have been achieved since the last meeting?
    • Are there new tasks? New requirements?
    • What is blocking? Any impediments?
  • If decisions have to be taken, the Scrum Master should take them quickly, within an hour if possible
  • The Scrum Master should deal quickly with any impediments and communication issues
  • Scrum teams should preferably operate from the same room

 
Conclusion

As for all Agile methods, the Scrum approach is best suited for new projects created from scratch. Over time, when successive application releases are implemented, the project can slowly transform into a continuous integration or even maintenance project, where less stakeholders input or daily supervision is required. The cogs are well oiled and operate naturally.

Reference: Introduction To Scrum



About the author

 Welcome to this web site . This page has two purposes: Sharing information about my professional life such as articles, presentations, etc.
This website is also a place where I would like to share content I enjoy with the rest of the world. Feel free to take a look around, read my blog


Java,J2EE,Spring Framework,JQuery,

Hibernate,NoSql,Cloud,SOA,Rest WebService and Web Stack tech...

RecentPosts

Month List

Sign In