The core targets for the v1.7 version have been achieved, and we now move into document writing and packaging.
Here is the final layout for the main window.
Thursday, 29 March 2012
Woohoo! It's done!
Today marks the end of the main coding of EISNet v1.7. This means, other than major bugs between now and release, the code is now finalised.
The core targets for the v1.7 version have been achieved, and we now move into document writing and packaging.
Here is the final layout for the main window.
The core targets for the v1.7 version have been achieved, and we now move into document writing and packaging.
Here is the final layout for the main window.
Friday, 16 March 2012
Approaching the end
The end of the development of v1.7 is very close. Closer than you think. Today I spent some time reviewing all the windows, giving them icons, checking fonts and positions etc. As any programmer knows, this is normally the last job before it goes out the door. Although I do have further bugs to fix, finalising the forms is almost like typing 'The end' to a novelist.
The product has had changes made which have then been removed a few months later. It's had new features added, and likewise, old and unused features removed. It's been all sorts of colours and patterns. Its also crashed a few times. But these are all in the natural timeline of a big development.
This is currently EISNet Management Studio and is likely to be exactly the same when you used it.
The next step is to fix the few remaining application bugs. Once these are fixed and confirmed, we move into deployment testing. This is where we build a new EISNet network from scratch direct to v1.7. We emulate the same scenario we would have at a customer site. This is likely to raise a number of packaging issues which will be addressed. This testing is scheduled to start in late June.
Then, in early July, we start doing upgrade testing. This is where we use an image of an EISNet v1.6 network and run the upgrade, once again emulating a real scenario.
Shortly after that, we then hit the packaging phase of the product where everything we have learn from the two previous tests is encapsulated into deployment services.
In late-July, we then start a short field test. If the field test shows no major issues, we will then start fresh builds in schools from August. Schools currently running v1.6 will then be optionally upgrades in the months that follow (we are unable to plan for any EISNet development or installations during the first few weeks in September due to the start of term)
In between April and June, it is full steam ahead for document writing, installation guides, management guides, help content, like web content and training EIS staff.
Exciting times ahead!
The product has had changes made which have then been removed a few months later. It's had new features added, and likewise, old and unused features removed. It's been all sorts of colours and patterns. Its also crashed a few times. But these are all in the natural timeline of a big development.
This is currently EISNet Management Studio and is likely to be exactly the same when you used it.
 |
| Main Window |
 |
| Package Manager |
The next step is to fix the few remaining application bugs. Once these are fixed and confirmed, we move into deployment testing. This is where we build a new EISNet network from scratch direct to v1.7. We emulate the same scenario we would have at a customer site. This is likely to raise a number of packaging issues which will be addressed. This testing is scheduled to start in late June.
Then, in early July, we start doing upgrade testing. This is where we use an image of an EISNet v1.6 network and run the upgrade, once again emulating a real scenario.
Shortly after that, we then hit the packaging phase of the product where everything we have learn from the two previous tests is encapsulated into deployment services.
In late-July, we then start a short field test. If the field test shows no major issues, we will then start fresh builds in schools from August. Schools currently running v1.6 will then be optionally upgrades in the months that follow (we are unable to plan for any EISNet development or installations during the first few weeks in September due to the start of term)
In between April and June, it is full steam ahead for document writing, installation guides, management guides, help content, like web content and training EIS staff.
Exciting times ahead!
The final test
There were 4 testers each equipped with a Server, and a station. They all ran their own tests in their own time and went on to find 65 bugs.
As of today, we are left with just 8.
A new logo
It is surprisingly difficult to create an icon for a product. Well, it's easy to find an icon, from the web, or another application, but to create one from scratch that embraces the philosophy of the product in hand is very hard indeed. Michael has been the artist in this area since I came on board. My icon creating skills are next to zero, so to have someone who is proficient in Adobe Photoshop is very handy. Michael has created the icons for EISNet v1.7 through the use of our own icon library, merging and adapting them where needed.
Throughout the entire project, I have been nagging him to get the actual EISNet Management Studio icon done. There have been many attempts and just as many failures (I am very hard to please). However, yesterday he gave me a surprise. He showed me the User Manager icon we use on our Administration Networks and suggested we use that. In theory, both tools do a similar job, but unfortunately where we have Joint Admin and Curriculum networks, it will become hard to determine which is which. So he then changed the colour scheme and the new EISNet Management Studio icon was born.
Tuesday, 13 March 2012
Minor tweaks and updates
Hyperlinks
Sometimes you need to deploy a link to a website to users. Previously, in EISNet v1.6 and below, you could do this by creating a shortcut to iexplore.exe and pass it the website as the parameter. Whilst this works, it didn't necessarily give you the correct icon. Instead, it was the Internet Explorer 'e' logo.
64bit shortcuts
EISNet v1.7 now supports the use of links as shortcuts. This means, if you create a shortcut to a URL - regardless if it starts HTTP:// or simply bbc.co.uk, you will see the correct icon and more importantly, you can do this without the use of using iexplore.exe.
The final change for the new version has been to fix a rather annoying issue with 64bit operating systems. Well, it's not so much a problem with 64bit systems themselves, its the creating of shortcuts. Traditionally, the problem with this is that a 64bit Operating System has two Program Files folders. One is called just that - "Program Files" and the other is called "Program Files (x86)". All 64bit software will get installed to Program Files and all 32bit software will be installed to the (x86) location. This presents a problem for network managers who have a mixture of 32bit and 64bit hardware across the site.
If, for example, you install a product that is 32bit (like Paint.Net for example) on a 32bit operating system, it will be installed to C:\Program Files. The same package however will install to C:\Program Files (x86) on a 64bit platform. Creating a shortcut to this can be problematic.
EISNet v1.7 now handles this with a little bit more intelligence. The shortcut you create will now ignore the Program Files location and decide which to use based on the operating system and product type. It works out which version is installed and creates the correct shortcut for you. Therefore, when you create the shortcut in Manager, you can enter either the 32 or 64bit version of the program files folder, and the correct one will be used when the user logs in.
Final testing
Tomorrow marks the final push for bugs as we complete our last bug sprint. A group of us will be pushing the software hard to squeeze as many bugs out of it as we can before final release. These bugs will then be fixed over the course of the coming weeks.
I will update during the day with our progress.
Sometimes you need to deploy a link to a website to users. Previously, in EISNet v1.6 and below, you could do this by creating a shortcut to iexplore.exe and pass it the website as the parameter. Whilst this works, it didn't necessarily give you the correct icon. Instead, it was the Internet Explorer 'e' logo.
64bit shortcuts
EISNet v1.7 now supports the use of links as shortcuts. This means, if you create a shortcut to a URL - regardless if it starts HTTP:// or simply bbc.co.uk, you will see the correct icon and more importantly, you can do this without the use of using iexplore.exe.
The final change for the new version has been to fix a rather annoying issue with 64bit operating systems. Well, it's not so much a problem with 64bit systems themselves, its the creating of shortcuts. Traditionally, the problem with this is that a 64bit Operating System has two Program Files folders. One is called just that - "Program Files" and the other is called "Program Files (x86)". All 64bit software will get installed to Program Files and all 32bit software will be installed to the (x86) location. This presents a problem for network managers who have a mixture of 32bit and 64bit hardware across the site.
If, for example, you install a product that is 32bit (like Paint.Net for example) on a 32bit operating system, it will be installed to C:\Program Files. The same package however will install to C:\Program Files (x86) on a 64bit platform. Creating a shortcut to this can be problematic.
EISNet v1.7 now handles this with a little bit more intelligence. The shortcut you create will now ignore the Program Files location and decide which to use based on the operating system and product type. It works out which version is installed and creates the correct shortcut for you. Therefore, when you create the shortcut in Manager, you can enter either the 32 or 64bit version of the program files folder, and the correct one will be used when the user logs in.
Final testing
Tomorrow marks the final push for bugs as we complete our last bug sprint. A group of us will be pushing the software hard to squeeze as many bugs out of it as we can before final release. These bugs will then be fixed over the course of the coming weeks.
I will update during the day with our progress.
Saturday, 3 March 2012
The final stretch
The home stretch
Exciting news. We are now moving into the final phase of development. All core modules have now been reviewed, modified, re-written or improved.
The last of these modules is LoginScript. This tool is used to customize the desktop appearance and set user customisation. It also handles the shortcut deployment where needed. Next to Manager, this has the biggest code set in the EISNet modules. Over the past week we have gone through it's 8,000 lines of code and removed code no longer needed and where possible, streamlined and improved the code. I'm happy to report the code is now at a little under 1,100 lines of code since the cleanup. That's a massive improvement.
As you know, we have moved away from a modular approach for EISNet and instead are now using a single tool. As a result we felt the term 'Manager' was no longer appropriate as it did not incorporate the Supervisor, Archivist and Package Manager tools in the name.
Therefore, I'm please to announce the new name for what was 'Manager'.
In EISNet v1.7, you'll be using EISNet Management Studio.
So whats next for the development?
Whilst all the modules have been adapted into v1.7, now comes a largely tougher, but altogether more pleasing area of development. Final testing begins now with the focus being on usability and reliability. We now need to remove all the bugs we've introduced over the past year of development. In a couple of weeks we have dedicated testing day, similar to the day we did last year. The plan is to have 5 or 6 people all trying hard to break the code at the same time. All the bugs will be logged and fixed as required.
All feature and new coding must be completed by April. That is our deadline. After then, only major bug fixes are allowed. We then we move into manuals / documentation, training and packaging. In this time we will also be doing field testing in a few schools.
The planned release of Summer is still achieveable, although I have to admit, I would prefer automatic upgrades from v1.6 to 1.7 to be tested a little more before we do our first upgrade.
In the coming months I hope to do a review based on the past year with screenshots of progress along the way and insight into the development.
I have to be honest, when I took on this project, I did not expect it to take this long. I think I under estimated the size of the product, or - if i'm honest, the complete mess the code was in. Still, from v1.7, EISNet has a solid foundation which has the scope for much more improvement over the next few years.
Exciting news. We are now moving into the final phase of development. All core modules have now been reviewed, modified, re-written or improved.
The last of these modules is LoginScript. This tool is used to customize the desktop appearance and set user customisation. It also handles the shortcut deployment where needed. Next to Manager, this has the biggest code set in the EISNet modules. Over the past week we have gone through it's 8,000 lines of code and removed code no longer needed and where possible, streamlined and improved the code. I'm happy to report the code is now at a little under 1,100 lines of code since the cleanup. That's a massive improvement.
As you know, we have moved away from a modular approach for EISNet and instead are now using a single tool. As a result we felt the term 'Manager' was no longer appropriate as it did not incorporate the Supervisor, Archivist and Package Manager tools in the name.
Therefore, I'm please to announce the new name for what was 'Manager'.
In EISNet v1.7, you'll be using EISNet Management Studio.
So whats next for the development?
Whilst all the modules have been adapted into v1.7, now comes a largely tougher, but altogether more pleasing area of development. Final testing begins now with the focus being on usability and reliability. We now need to remove all the bugs we've introduced over the past year of development. In a couple of weeks we have dedicated testing day, similar to the day we did last year. The plan is to have 5 or 6 people all trying hard to break the code at the same time. All the bugs will be logged and fixed as required.
All feature and new coding must be completed by April. That is our deadline. After then, only major bug fixes are allowed. We then we move into manuals / documentation, training and packaging. In this time we will also be doing field testing in a few schools.
The planned release of Summer is still achieveable, although I have to admit, I would prefer automatic upgrades from v1.6 to 1.7 to be tested a little more before we do our first upgrade.
In the coming months I hope to do a review based on the past year with screenshots of progress along the way and insight into the development.
I have to be honest, when I took on this project, I did not expect it to take this long. I think I under estimated the size of the product, or - if i'm honest, the complete mess the code was in. Still, from v1.7, EISNet has a solid foundation which has the scope for much more improvement over the next few years.
Developing the impossible
Renaming devices
Most network management solutions such as EISNet do not support the renaming of a device. The problem is that whilst the device name may be changed, the database which manages the network will not know the new name.
EISNet v1.7 now has functionality built in to detect a name change on a workstation. This means, you can login to a workstation as an Administrator, rename it and on when it reboots, EISNet Client will detect this, and update the database accordingly.
In addition, we have now introduced a brand new feature in Manager which allows you to select a device and rename it remotely, from within Manager itself. The device will then optionally reboot.
Redeploying packages after a rebuild
From time to time it is necessary to rebuild (reinstall Windows) on a device. Sometimes this is due to problems, other times, the device might be replaced. In EISNet, it was not possible to rebuild a work station and automatically redeploy the packages to the device. Previously you would rebuild the work station, then use Manager to reassign the packages.
In EISNet v1.7, this is no longer the case. EISNet Client is now intelligent enough to know when the device has been rebuilt. When this happens, Client will automatically re-install packages.
Subscribe to:
Posts (Atom)