I installed iOS 5 on my iPhone 3GS. It was a rough start, but I am happy with the end result.
For the last several iterations of the iOS on my 3GS has really slowed it down. The latest 4.3.5, slowed down my phone so much that I was thinking Apple was purposely slowing down the 3G series phones to force them to upgrade to the 4S. Unlike Microsoft that benifits from speeding up old hardware, Apple requires new products to be moving all of the time to keep their stock price up, and their company solvent, as no one can install their OS or use their software on anything other than Apple provided hardware... and Jobs said that Bill Gates was too uptight.. So slowing down older hardware would be right in their best interests, and therefore not a large logical leap to assume it was happening.
With iOS5, I found that my phone not only performs much faster, the battery life and the signal strength seem to have improved as well. I can't yet tell about calls dropped, as I have not had the time to really test that particular annoyance of the iPhone out completely. Weather this is simply a new algorithm used to compute the signal and battery strength I have no idea. I do remember seeing my signal strength greatly improve when I installed iOS4, only to be disappointed later when I found out that Apple was displaying strength greater than what the strength really was. This could be more of the same, but I want to believe that Apple has improved their software and thus found ways to improve their power usage, and to detect signal.
The new features are very welcome, especially the new camera features. The camera can now be accessed from the locked screen and you can take a photo by pressing the up button on the volume hard button. Infinitely easier to take a photo of yourself using this method than trying to find the soft button. I would always miss and end up in the photo album...
The new notification center is also very cool. You get a plethora of app data in there accessed by simply pulling it down from the top where the clock usually is. I know this is a feature they stole from Android, but it is a welcome addition.
Being able to choose how notifications are done is a great change as well. You can have your less important push notifications sent to a banner rather than to the non modal alert box. Very nice very good.
Apple is pushing iCloud, but I really am not very interested in that. I might be later, but right now... Meh.
The final new feature that I really like is that you no longer need to attach the phone to iTunes to update the software. This is a BIG help. However it kind of spooks me, because of my experience with updating my phone to iOS5.
During the install, my phone crashed, and I had to restore it back to factory preset, then I had to restore my settings and Apps. Then I had to put those apps back in to their folders. That took a long time and it sucked. Double sucked... If I were performing this update with out iTunes, would I be out of luck? With iTunes, I get a backup and I can restore the phone to somewhat of a state that it was in before. With out iTunes, will the phone just puke and then be dead? Something to think about... I know you are thinking, what about the backup that is made on iCloud. Think about it, what if I do a phone update somewhere I don't have access to a computer with iTunes for some time. Without the computer, I can't set the phone back to factory then do the restore of the phone. Will the phone just be toast until I can find some computer to plug it in? Or does the phone update by throwing everything in to memory... Sounds very inefficient, and lots of security problems come immediately to mind, but that never bothered Apple before...
All in all, good update, and I reccomend it for all of the iPhone 3GS users out there. With this update I think I can put off getting the next version of the iPhone until iPhone 5 comes out.
Thursday, October 13, 2011
Wednesday, October 5, 2011
Hiring for SharePoint
I am at the SharePoint 2011 Conference this week and I have found a reoccurring theme popping up with the manager types that come to the conference. Most of them are overwhelmed with the breadth of the SharePoint product, and nearly all of them realize that what they have in place to support SharePoint is not what they need.
I was talking to some of the other participants about a particular project they were involved it. He was involved in trying to deploy SharePoint as a fault tolerant system, and I was running down what he needed to do. We noticed that we were attracting a lot of attention from the leader types. You know, they are the guys in the button up shirts trying not to look lost in the sea of geeks. After a bit, the managers started to ask about how they could go about hiring the right people to set up their SharePoint environments "right." The first thing I said was that to set up their SharePoint environments "right," they needed to spend some serious money. In my experience, SharePoint needs a dedicated cross-functional team in order to be successfully deployed and maintained. The word that really stuck in the manager's craw is "dedicated." Even after seeing all of what SharePoint can do, they still believed that there would not be enough work for dedicated staff. This just isn't true. At any company were there is not dedicated SharePoint staff, immediate problems start to pop up, mostly surrounding the direction of the product, and what it can do. If staff is not dedicated, there is no incentive for an individual to study the features of SharePoint, and find out how it can be best used in the company. There is no one to support the product, leaving the end users wondering how to use it. Essentially, if you don't have dedicated staff, you are throwing the product down the tubes, and dooming your deployment for failure.
As to the hiring question... This spawned a long and interesting conversation about how many people were needed, getting input from the tech side, me, and the business side, them. All in all, those that accepted the fact that they need dedicated staff saw value in the team that I suggested.
In my ideal deployment, and this means ANY deployment, from one server to 10,000, you are going to need four roles; Architect, Administrator, Designer, and Developer. The most important, most senior, and most critical is the Architect role. This person will lead the team, develop the overall vision of the deployment, be the chief evangelist, and mentor the other roles. As you can imagine, this role is also the most difficult to hire.
Architect
This should be the first person that is hired, and should do the hiring for the rest of the team. This is a special person, because they need to have a split IT personality. In that I mean that they need to have experience with software development, and systems administration. It helps if they also have some Network Engineering in their background as well. What I mean by software development experience, is that they need to have a firm grasp of OOP, the .NET Framework, and modern design principals. They need to have written code as a developer on a software team. A person who has written code, but as a one project, one programmer shop is not your ideal candidate, as these developers often have a tough time leading a team of people.
They need to have designed and written WCF services, web services, and windows services. They need to know the role that each play, and how to integrate them in to a cohesive SOA. After all that... They need to have a good grasp of the SharePoint API, and they need to have written and deployed the major pieces involved in SharePoint development. What major pieces? Web parts, timer jobs, site definitions, and workflows. They need to know what each part does and what problems each solves.
The Architect should be able to speak to the database staff about indexes, backups, and SharePoint database architecture. They should also have a good grasp of what Remote BLOB storage is and when it is a good idea. They should be able to present this to the database staff.
On the other side of the IT fence, the Architect needs to know how SharePoint is installed, configured, deployed, and maintained. In other words, this person needs to have spent time as a professional SharePoint Administrator. As an administrator this person should have handled at least one major farm migration. This will ensure that they know what is involved in a migration, and that they have all of the lessons learned from that migration. It also ensures that they have been involved in SharePoint long enough to have seen where Microsoft has come with the product, and have some idea on where Microsoft is going with the product.
They need to have planed for and executed disaster recovery plans with SharePoint, and should be very comfortable with recovery scenarios, from a total loss of the farm, to the loss of a single file.
They should be well versed on search. How SharePoint does it, what the limitations of the Out Of the Box search features are, and when it is a good idea to put FAST Search in. They should know how to configure search so that it will return the proper results.
They also need to be a very well rounded IT person. They should know about the different methods on how to make SQL redundant, they should know how to load balance a web server, they should know what LDAP is, and what a good Active Directory design consists of and how it will impact the SharePoint deployment.
With all of this experience, it will be very difficult to interview for this position. You have to accept that the SharePoint stuff you will have to simply ask about and hope that they give you a straight answer. You are an IT manager, so hopefully you have some skill in the area of bullshit detection... If you have development staff, bring in a developer to aid in the interview. You will get a good grasp of their development skills from your trusted developer. Also bring in one of your Systems Engineers to find out what they know about AD and other Windows related services. If you have web staff, bring one in to discuss web topics. Your trusted staff should be able to give a good rundown on the candidate's general skill. From this you should be able to judge if the candidate is being truthful about what is on their resume.
Here are some of the qualities that I think that an Architect should have personally:
With all of the above, you must realize that this person will not come cheap. This kind of skill comes at a premium, and you have to giver proper incentive for them to stay. The good news it that you can save money on the other members of the team.
Administrator
The Administrator position is going to be easier to find. You can ask for some SharePoint administration experience, but it really isn't required, especially if you want to save some money on this position. In a perfect world, this position will have about 2 years experience with SharePoint as an IT pro.
The necessary skills, in my opinion, are going to center around, in order of importance, IIS, PowerShell, software deployment, Windows, and experience supporting "N" tier applications. SharePoint experience would fit somewhere between Windows and supporting "N" tier applications.
IIS is the key in this position, because SharePoint is a .NET program hosted in IIS. Without a firm grasp on how IIS works, how applications are hosted, how WAS works, the administrator will fall flat on his face when the fit hits the shan. SharePoint deals heavily in Web Services and WCF and if the administrator has never supported those two things in IIS, they will be baffled on why the sections hosting the different technologies use the same authentication, but have different settings in IIS. Without web experience, the critical difference between a web application and a web site will trip them up. These things are vital to the SharePoint farm.
I would like this person to be up on the latest load balancing techniques so that they can put in to practice the load balancing methods that the Architect selects for the deployment, but this is not necessary and it can be something that the Architect mentors the Administrator on.
Experience with PowerShell is absolutely vital. Much of SharePoint administration is done through PowerShell, and many tasks can be automated with PowerShell. Being only one person, the Administrator who only uses Central Administration can only do so much. The Administrator who automates and scripts tasks multiplies their worth to the company, by being able to clone themselves many times over. Also, many tasks need to be handled off hours, the stupid Administrator stays late, or remotes in from home to complete these tasks via Central Administration. The smart, savvy Administrator, the one you want to hire, scripts all off hour tasks and has the script send him email confirmations of task completion or failure. No muss no fuss. An Administrator that automates the most common tasks also builds in automatic redundancy for themselves and has more time to focus on interesting and important work, R&D, and preventative maintenance. The administrator who does not script is constantly putting out fires, repeating the same tasks over and over, and never seems to have any time to R&D and do anything preventative.
As the developers will be handing the Administrator their code to deploy, it is a good idea to look for an IT Pro with experience in deploying software. Again, you want to see this person insist on scripted deployments, as well as packaged solutions. It makes their job easier, and makes a solid repeatable, predictable deployment the rule rather than the exception.
Supporting "N" tier applications forces the Administrator to always be thinking about what service is calling what. It also will mean that the candidate knows about authentication methods that can handle multi-server hops, or what must happen so that authentication methods that can not multi-hop on their own make those vital hops.
Developer
Again, it is not vital that the Developer have SharePoint development experience. It is vital, however, that the Developer have .NET web development experience. From the developer standpoint, SharePoint is just another API to call. Take away the funky deployment, and SharePoint development is just like any other development, inherit a base class, and implement a method. A week training class will get the Developer up to speed on SharePoint development. After that the Architect will be able to mentor them and guide them to become SharePoint developers.
What we do want out of a developer is a deep sense of curiosity. We want them to want to know why things work the way that they do, and once they know that, they should wonder how they can manipulate those things to fit what the business wants to do.
Designer
The most common flaw that very technical people have is that they have no eye for the aesthetic. Their art is in their code, or in how smoothly their servers run. Unfortunately, no matter how brilliant the code behind the site may be, if it is not pleasing to the eye, or if the user experience is bad, the deployment will fail. This is where the Designer comes in. The designer is a person who should be able to design functional, pretty, web sites. I also like my designer to be experts in the client side scripting languages that make their visions possible. JavaScript, JQuery, CSS, Flash, and Silverlight should be on the Designer's resume along with the ability to work with technical people. In my opinion the designer should be able to create a UI, then hand that UI off to the developer to wire up the functionality. In other words the Designer creates the button and puts it on the page, the Developer takes over at the mouse click.
It is not required that the Designer know about SharePoint. SharePoint experience is good, but it is far from the most vital thing you are looking for.
DBA
This last position is not listed above on my three position team list because this position does not need to be 100% dedicated to SharePoint. SharePoint handles most of the database work all on its own, with as little human interaction as possible. BUT since a major part of the SharePoint functionality depends on the database it is important to have a DBA that can be the "go-to" person with SharePoint team issues. It will be up to the DBA and the Architect to make the redundancy decisions with regards to the SQL farm. If the Developer needs to hit an external database for some reason, the DBA is who they go to to get permissions and other things in line. When the Administrator is setting up Business Intelligence, they will need the DBA to create data cubes in Analysis Services.
With these positions filled, your SharePoint deployment is set up for success. SharePoint is a unique product, and not one that can simply be thrown in to an environment. It needs dedicated people to support and maintain it so that you can get the most out of the product.
I was talking to some of the other participants about a particular project they were involved it. He was involved in trying to deploy SharePoint as a fault tolerant system, and I was running down what he needed to do. We noticed that we were attracting a lot of attention from the leader types. You know, they are the guys in the button up shirts trying not to look lost in the sea of geeks. After a bit, the managers started to ask about how they could go about hiring the right people to set up their SharePoint environments "right." The first thing I said was that to set up their SharePoint environments "right," they needed to spend some serious money. In my experience, SharePoint needs a dedicated cross-functional team in order to be successfully deployed and maintained. The word that really stuck in the manager's craw is "dedicated." Even after seeing all of what SharePoint can do, they still believed that there would not be enough work for dedicated staff. This just isn't true. At any company were there is not dedicated SharePoint staff, immediate problems start to pop up, mostly surrounding the direction of the product, and what it can do. If staff is not dedicated, there is no incentive for an individual to study the features of SharePoint, and find out how it can be best used in the company. There is no one to support the product, leaving the end users wondering how to use it. Essentially, if you don't have dedicated staff, you are throwing the product down the tubes, and dooming your deployment for failure.
As to the hiring question... This spawned a long and interesting conversation about how many people were needed, getting input from the tech side, me, and the business side, them. All in all, those that accepted the fact that they need dedicated staff saw value in the team that I suggested.
In my ideal deployment, and this means ANY deployment, from one server to 10,000, you are going to need four roles; Architect, Administrator, Designer, and Developer. The most important, most senior, and most critical is the Architect role. This person will lead the team, develop the overall vision of the deployment, be the chief evangelist, and mentor the other roles. As you can imagine, this role is also the most difficult to hire.
Architect
This should be the first person that is hired, and should do the hiring for the rest of the team. This is a special person, because they need to have a split IT personality. In that I mean that they need to have experience with software development, and systems administration. It helps if they also have some Network Engineering in their background as well. What I mean by software development experience, is that they need to have a firm grasp of OOP, the .NET Framework, and modern design principals. They need to have written code as a developer on a software team. A person who has written code, but as a one project, one programmer shop is not your ideal candidate, as these developers often have a tough time leading a team of people.
They need to have designed and written WCF services, web services, and windows services. They need to know the role that each play, and how to integrate them in to a cohesive SOA. After all that... They need to have a good grasp of the SharePoint API, and they need to have written and deployed the major pieces involved in SharePoint development. What major pieces? Web parts, timer jobs, site definitions, and workflows. They need to know what each part does and what problems each solves.
The Architect should be able to speak to the database staff about indexes, backups, and SharePoint database architecture. They should also have a good grasp of what Remote BLOB storage is and when it is a good idea. They should be able to present this to the database staff.
On the other side of the IT fence, the Architect needs to know how SharePoint is installed, configured, deployed, and maintained. In other words, this person needs to have spent time as a professional SharePoint Administrator. As an administrator this person should have handled at least one major farm migration. This will ensure that they know what is involved in a migration, and that they have all of the lessons learned from that migration. It also ensures that they have been involved in SharePoint long enough to have seen where Microsoft has come with the product, and have some idea on where Microsoft is going with the product.
They need to have planed for and executed disaster recovery plans with SharePoint, and should be very comfortable with recovery scenarios, from a total loss of the farm, to the loss of a single file.
They should be well versed on search. How SharePoint does it, what the limitations of the Out Of the Box search features are, and when it is a good idea to put FAST Search in. They should know how to configure search so that it will return the proper results.
They also need to be a very well rounded IT person. They should know about the different methods on how to make SQL redundant, they should know how to load balance a web server, they should know what LDAP is, and what a good Active Directory design consists of and how it will impact the SharePoint deployment.
With all of this experience, it will be very difficult to interview for this position. You have to accept that the SharePoint stuff you will have to simply ask about and hope that they give you a straight answer. You are an IT manager, so hopefully you have some skill in the area of bullshit detection... If you have development staff, bring in a developer to aid in the interview. You will get a good grasp of their development skills from your trusted developer. Also bring in one of your Systems Engineers to find out what they know about AD and other Windows related services. If you have web staff, bring one in to discuss web topics. Your trusted staff should be able to give a good rundown on the candidate's general skill. From this you should be able to judge if the candidate is being truthful about what is on their resume.
Here are some of the qualities that I think that an Architect should have personally:
- Passionate about SharePoint, this should be evident in the interview.
- Passionate about IT in general.
- They should have some decent social skills. They will end up being a cheerleader and evangelist for SharePoint and its features as well as effectively lead the SharePoint team. Thus, they have to be able to communicate effectively with other humans.
With all of the technical skill we are asking for, this particular feature will be some of the hardest to meet... - They should be worried with improving their skills. They will ask about training and conference budgets.
With all of the above, you must realize that this person will not come cheap. This kind of skill comes at a premium, and you have to giver proper incentive for them to stay. The good news it that you can save money on the other members of the team.
Administrator
The Administrator position is going to be easier to find. You can ask for some SharePoint administration experience, but it really isn't required, especially if you want to save some money on this position. In a perfect world, this position will have about 2 years experience with SharePoint as an IT pro.
The necessary skills, in my opinion, are going to center around, in order of importance, IIS, PowerShell, software deployment, Windows, and experience supporting "N" tier applications. SharePoint experience would fit somewhere between Windows and supporting "N" tier applications.
IIS is the key in this position, because SharePoint is a .NET program hosted in IIS. Without a firm grasp on how IIS works, how applications are hosted, how WAS works, the administrator will fall flat on his face when the fit hits the shan. SharePoint deals heavily in Web Services and WCF and if the administrator has never supported those two things in IIS, they will be baffled on why the sections hosting the different technologies use the same authentication, but have different settings in IIS. Without web experience, the critical difference between a web application and a web site will trip them up. These things are vital to the SharePoint farm.
I would like this person to be up on the latest load balancing techniques so that they can put in to practice the load balancing methods that the Architect selects for the deployment, but this is not necessary and it can be something that the Architect mentors the Administrator on.
Experience with PowerShell is absolutely vital. Much of SharePoint administration is done through PowerShell, and many tasks can be automated with PowerShell. Being only one person, the Administrator who only uses Central Administration can only do so much. The Administrator who automates and scripts tasks multiplies their worth to the company, by being able to clone themselves many times over. Also, many tasks need to be handled off hours, the stupid Administrator stays late, or remotes in from home to complete these tasks via Central Administration. The smart, savvy Administrator, the one you want to hire, scripts all off hour tasks and has the script send him email confirmations of task completion or failure. No muss no fuss. An Administrator that automates the most common tasks also builds in automatic redundancy for themselves and has more time to focus on interesting and important work, R&D, and preventative maintenance. The administrator who does not script is constantly putting out fires, repeating the same tasks over and over, and never seems to have any time to R&D and do anything preventative.
As the developers will be handing the Administrator their code to deploy, it is a good idea to look for an IT Pro with experience in deploying software. Again, you want to see this person insist on scripted deployments, as well as packaged solutions. It makes their job easier, and makes a solid repeatable, predictable deployment the rule rather than the exception.
Supporting "N" tier applications forces the Administrator to always be thinking about what service is calling what. It also will mean that the candidate knows about authentication methods that can handle multi-server hops, or what must happen so that authentication methods that can not multi-hop on their own make those vital hops.
Developer
Again, it is not vital that the Developer have SharePoint development experience. It is vital, however, that the Developer have .NET web development experience. From the developer standpoint, SharePoint is just another API to call. Take away the funky deployment, and SharePoint development is just like any other development, inherit a base class, and implement a method. A week training class will get the Developer up to speed on SharePoint development. After that the Architect will be able to mentor them and guide them to become SharePoint developers.
What we do want out of a developer is a deep sense of curiosity. We want them to want to know why things work the way that they do, and once they know that, they should wonder how they can manipulate those things to fit what the business wants to do.
Designer
The most common flaw that very technical people have is that they have no eye for the aesthetic. Their art is in their code, or in how smoothly their servers run. Unfortunately, no matter how brilliant the code behind the site may be, if it is not pleasing to the eye, or if the user experience is bad, the deployment will fail. This is where the Designer comes in. The designer is a person who should be able to design functional, pretty, web sites. I also like my designer to be experts in the client side scripting languages that make their visions possible. JavaScript, JQuery, CSS, Flash, and Silverlight should be on the Designer's resume along with the ability to work with technical people. In my opinion the designer should be able to create a UI, then hand that UI off to the developer to wire up the functionality. In other words the Designer creates the button and puts it on the page, the Developer takes over at the mouse click.
It is not required that the Designer know about SharePoint. SharePoint experience is good, but it is far from the most vital thing you are looking for.
DBA
This last position is not listed above on my three position team list because this position does not need to be 100% dedicated to SharePoint. SharePoint handles most of the database work all on its own, with as little human interaction as possible. BUT since a major part of the SharePoint functionality depends on the database it is important to have a DBA that can be the "go-to" person with SharePoint team issues. It will be up to the DBA and the Architect to make the redundancy decisions with regards to the SQL farm. If the Developer needs to hit an external database for some reason, the DBA is who they go to to get permissions and other things in line. When the Administrator is setting up Business Intelligence, they will need the DBA to create data cubes in Analysis Services.
With these positions filled, your SharePoint deployment is set up for success. SharePoint is a unique product, and not one that can simply be thrown in to an environment. It needs dedicated people to support and maintain it so that you can get the most out of the product.
Subscribe to:
Posts (Atom)