Monday 26 May 2014

Web Response

Web Response Time

Harping on the response time of a web application.

Something for us to think about.

A user wants to feel like they are manipulating the system, they want to feel the response, they want to control what is happening. Make sure user actions on a application take under 0.1 Second to register and respond to the server.

When the user does something that they expect the system to process or do something with the information the response time is upped to 0.2-1.0 Second. This lets the user feel like the system is working on the command.

Although the upper limit of the users attention is about 10 seconds, and yes roughly estimated, as each user is different, but after those precious seconds the user has lost concentration with what they were doing and is most likely to move along to the next task at hand.


Wait what?

Thursday 22 May 2014

Web Response Time

Response Times.

Unfortunately, most of us use some sort of the web on a daily basis, you being here right now, implies that the statement is true, well at least for you.

The biggest frustration on the web, is the time at which pages take to load. The current project I am on at the moment, had issues of that sort, where the pages were take 10 Seconds+ to load, on a good day. Granted this was on Dev, it was not acceptable, and unfortunately I was very busy and could only focus minimal hours a day on it.

One morning not so long ago, I was called into a meeting, where the executives for the consulting house I work for were in discussion with a few of my colleagues about the speed of the applications we were writing and using. Where we would sit and wait for a while before a page would complete loading. We could nearly have a full discussion on the topic before the page would load.

This was a growing concern with them, and a plan was put into place where the team were supposed to go back and find out some things about the speeds of their respective applications. We had a teasing team put a plan in place to see exactly what was happening, page loads, find some base lines. I was not part of the team, but I did some testing of myself.

I came up with a few baselines, mostly when the network was not under stress. The scary part about all this was that the pages would be taking 10+ Seconds to load. With the fastest being the login page where there was two pictures, relatively small, and the login form. With this page taking about 6 seconds to load, pictures and all.

After about a week of this hype within the team, where there was only a real hype from the team that was actively looking into the problem. There was barely any movement from there, and about a week later this so called problem with fully blown plan just died, no more mention about the beast. Although the whole team knew about this issue, there was little done from a testing perspective there on out.

Unfortunately, we are in a world where we are used to everything fast, from our cars that we drive to the cell phones we have in our hands, even the coffee machine is making us a cup of coffee within a few seconds. We are based in a world where speed is everything. Every seconds counts.

Some scary facts are that, if a page takes longer than 3 seconds to load, a user has a 45% to abandon the page. About 50% of us, expect a page to take under 2 seconds to load. Now thing about that for a second or three. How likely are you to leave a page if it takes a few seconds to load?
Can you just imagine what would happen if Google took longer than 2 seconds to load. Wow, the world would crash.

Now a average user is not willing to wait 10 seconds for a page to load. What would make this any different.

With that at the back of your mind, don't you think performance is something to always keep at the back of your mind while doing something for a customer?  Every Developer should remember these points. 1 Second may just one day be a million dollar mistake.  Think about it one second may cost you a fortune.

#bearMan saving you Time.

Hardware cant solve every issue.

Monday 12 May 2014

LDIF Modify Group - Add New Members

LDIF Modify Group - Add New Members

dn: cn=iFACTORY,cn=groups,dc=MyCompany,dc=com
changetype: modify
add: uniquemember
uniquemember: cn=user1,cn=users,dc=MyCompany,dc=com
uniquemember: cn=user2,cn=users,dc=MyCompany,dc=com
uniquemember: cn=user3,cn=users,dc=MyCompany,dc=com

#bearMan, saving Myself Time

Thursday 1 May 2014

Setting Up a Virtual Machine for Linux x64

Setting Up a Virtual Machine for Linux x64

I am going to demonstrate to you how to prep your Oracle Virtual Box.

You can download VirtualBox From:

Create a new Virtual Machine

Allocate the amount of RAM Machine Will Have

Choose Create new Virtual HDD Now
Select HDD Type: I would use VDI, but it is up to you

Select Dynamically Allocated: (This basically means the Virtual Drive will expand, as needed, until full size)

Choose Size and Location

Once you have done that, select your Virtual Machine and Press
Ctrl + S

Once there go into System -> Processor and allocate number of CPU's I would recommend using more than one!
If you want you can also add the machine to your network:

Now that you have done this, you have a basic working Virtual Machine.

I would recommend adding more Video Memory but this is not a Must.