Today I sent an email to around 60 community groups based in Warrington to ask if they would like any help from me on a volunteer basis. I have tried looking for volunteer work before through the IT4Communities website but not had any takers.
I understand from working with community groups and small businesses on the Knowsley Community Tradenet project that time is the scarcest resource for the people who run these organisations and I hope that by offering my time and skills I can maybe help one or two IT - based projects get off the ground.
I took a list of contacts from the Warrington Community Information Directory.
Sunday, 26 December 2010
Wednesday, 22 December 2010
Team Foundation Server 2010 (3)
Came across a problem referencing a .dll today. The application that I am migrating into TFS2010 as part of the learning process relies quite heavily on the Ajax Control Toolkit for its UI and the .dll has to be included as part of the solution.
Unfortunately it's not enough to reference the library as was the norm in VS2008 because the build server couldn't see it. I tried creating a folder called C:\Build on my laptop and the build server and placing the file in both these locations but that didn't solve it either. Fortunately I found the answer about half way down this thread; you have to include the .dll in the workspace structure of the solution otherwise it won't work. So I created a folder called References inside the project folder of the branch I'm trying to build, added the .dll to it and then referenced the .dll from this location in my VS2010 solution. Worked like a charm.
It looks like TFS ignores any .dll you add this way for build purposes; I guess you don't want your build failing because the 3rd party .dll you are using has an unassigned variable lurking. I then tried merging the dev branch into main to see if TFS was smart enough to replicate the referencing and it was, there is now a folder called References in the Main workspace and the solution file for Main contains a reference to that file. Very slick indeed.
Unfortunately it's not enough to reference the library as was the norm in VS2008 because the build server couldn't see it. I tried creating a folder called C:\Build on my laptop and the build server and placing the file in both these locations but that didn't solve it either. Fortunately I found the answer about half way down this thread; you have to include the .dll in the workspace structure of the solution otherwise it won't work. So I created a folder called References inside the project folder of the branch I'm trying to build, added the .dll to it and then referenced the .dll from this location in my VS2010 solution. Worked like a charm.
It looks like TFS ignores any .dll you add this way for build purposes; I guess you don't want your build failing because the 3rd party .dll you are using has an unassigned variable lurking. I then tried merging the dev branch into main to see if TFS was smart enough to replicate the referencing and it was, there is now a folder called References in the Main workspace and the solution file for Main contains a reference to that file. Very slick indeed.
Tuesday, 21 December 2010
Team Foundation Server 2010 (2)
I've spent the majority of the day trying to teach myself how to set the server up and how it works with Visual Studio 2010. Fortunately it's all pretty intuitive and I think I have it figured out to a level where the team can make use of it. It is going to save us a lot of time and make us work better.
There were a few different topics that I looked at. I followed Jason Zander's tutorial on his blog and that taught me how to do the install, create a project in TFS and then add code to it from VS2010 and make changes. What this doesn't go into is two slightly more advanced topics - using the Source Control Explorer and Branching. It also skips over Workspaces (basically the 'Set Working Directory' option that was in Visual Source Safe).
Branching allows you to create multiple copies of the same application and keep them in different states simultaneously. The simple example I saw on Codeplex has a three Branches - Main, Dev and Release. The Dev Branch allows the dev team to work on one copy of the application while the Main and Release Branches are kept 'clean'. When the dev team has completed something and tested it the changes can be merged into Main and Release, built and published. Another benefit of this is that if something urgently needs doing to the Release version you can implement the change on Release and propagate the change back down to Main and Dev. This seems like a really powerful tool.
The Source Control Explorer is what manages these Branches. Once you have created the Main Branch you can populate it with a blank solution from VS2010 and then Merge this into the other Branches. I guess there's maybe room for a Test Branch too.
Creating a Build is really easy (once you figure out how to give the correct permissions to write to the build folder on the server) and it drops out a compiled web app which you can quickly drop onto a server. You can specify builds for the different Branches and schedule these to run multiple times throughout the day. I guess the dev build needs to happen pretty frequently, the release build could be run manually to save the server overhead.
The irritations caused by Source Safe are pretty much gone. Tomorrow I'm going to install VS2010 on another development laptop and see how easy / difficult it is to get a copy of the source code and make changes to it.
There were a few different topics that I looked at. I followed Jason Zander's tutorial on his blog and that taught me how to do the install, create a project in TFS and then add code to it from VS2010 and make changes. What this doesn't go into is two slightly more advanced topics - using the Source Control Explorer and Branching. It also skips over Workspaces (basically the 'Set Working Directory' option that was in Visual Source Safe).
Branching allows you to create multiple copies of the same application and keep them in different states simultaneously. The simple example I saw on Codeplex has a three Branches - Main, Dev and Release. The Dev Branch allows the dev team to work on one copy of the application while the Main and Release Branches are kept 'clean'. When the dev team has completed something and tested it the changes can be merged into Main and Release, built and published. Another benefit of this is that if something urgently needs doing to the Release version you can implement the change on Release and propagate the change back down to Main and Dev. This seems like a really powerful tool.
The Source Control Explorer is what manages these Branches. Once you have created the Main Branch you can populate it with a blank solution from VS2010 and then Merge this into the other Branches. I guess there's maybe room for a Test Branch too.
Creating a Build is really easy (once you figure out how to give the correct permissions to write to the build folder on the server) and it drops out a compiled web app which you can quickly drop onto a server. You can specify builds for the different Branches and schedule these to run multiple times throughout the day. I guess the dev build needs to happen pretty frequently, the release build could be run manually to save the server overhead.
The irritations caused by Source Safe are pretty much gone. Tomorrow I'm going to install VS2010 on another development laptop and see how easy / difficult it is to get a copy of the source code and make changes to it.
Team Foundation Server 2010 (1)
I have been working as part of a team of six developers for just over a year now. This has been the first time in my career that I have been part of such a team and in that time we have created a lot of components. These are scattered across a range of applications - web apps, web services, databases, SSIS packages and standalone .exe files that we run from servers on a schedule.
We're at the stage now where controlling change amongst the team is difficult. We are using Visual Source Safe as our source code repository and it's not brilliant. I'm never 100% confident that when I try and build a new version of the application that I'm working on and publish it to our test environment that it will have all the most up to date code in it. So instead of moving forward with functionality I'm spending time bug fixing changes so that I can get a demo working for customers.
I'm also finding the whole build process very unsatisfactory. At the moment I have a Visual Studio 2008 solution with a dev project that we're all contributing to and a test project that contains just the files I need to run a particular app. Creating a build involves knowing which of the files have changed, copying them into the test project, remembering to change the namespaces and then publishing to the test server. It's a slow and irritating process.
I also have the attitude of team members to deal with. Communicating with people when you all sit in a space that's about 10m square should be simple but it's not. I'm not getting told when things change and only find out about changes when I try and publish a version of the app and it stops working because a datatype has changed in the database.
All this is stopping us progressing. Fortunately we have just acquired some MSDN developer licenses that allow us to install Visual Studio Pro 2010 and Team Foundation Server. I have been reading plenty of stuff on the web about how these development tools will help to resolve the problems that I'm facing and move the team forward. So I'm going to spend the next few months concentrating on developing the practices and procedures necessary to improve our efficiency and quality. I would also like to explore the opportunities that Agile programming will bring to the team and see how well it fits with what we do because I think we can learn from that too. The next set of blog posts will all record my findings as I carry out this piece of work.
We're at the stage now where controlling change amongst the team is difficult. We are using Visual Source Safe as our source code repository and it's not brilliant. I'm never 100% confident that when I try and build a new version of the application that I'm working on and publish it to our test environment that it will have all the most up to date code in it. So instead of moving forward with functionality I'm spending time bug fixing changes so that I can get a demo working for customers.
I'm also finding the whole build process very unsatisfactory. At the moment I have a Visual Studio 2008 solution with a dev project that we're all contributing to and a test project that contains just the files I need to run a particular app. Creating a build involves knowing which of the files have changed, copying them into the test project, remembering to change the namespaces and then publishing to the test server. It's a slow and irritating process.
I also have the attitude of team members to deal with. Communicating with people when you all sit in a space that's about 10m square should be simple but it's not. I'm not getting told when things change and only find out about changes when I try and publish a version of the app and it stops working because a datatype has changed in the database.
All this is stopping us progressing. Fortunately we have just acquired some MSDN developer licenses that allow us to install Visual Studio Pro 2010 and Team Foundation Server. I have been reading plenty of stuff on the web about how these development tools will help to resolve the problems that I'm facing and move the team forward. So I'm going to spend the next few months concentrating on developing the practices and procedures necessary to improve our efficiency and quality. I would also like to explore the opportunities that Agile programming will bring to the team and see how well it fits with what we do because I think we can learn from that too. The next set of blog posts will all record my findings as I carry out this piece of work.
Graduated!
Last week (Wednesday 15th December, 3pm to be precise) I attended my graduation ceremony at the Liverpool Philharmonic Hall and received my certificate from the vice chancellor. I am now officially a Master of Science! It was a great day and made a nice change to be in a room full of happy people all celebrating something.
Wednesday, 27 October 2010
ASP.NET ASCX controls and ViewState
I've written a scripting engine into the ASP.NET app that I am developing. It's pretty neat - the user can choose from a list of scripts to load and work through, the script is loaded into a panel and they can follow it through.
Identified a problem yesterday whereby the second and subsequent scripts that got loaded had a strange little error - the first server control in the script didn't work on its first event (i.e. click, selectedindexchanged). It would work the second time the control was used - but that's no good for the users.
So I set about trying to solve it. After about seven hours of reading, trying things out and getting really frustrated I did solve it thanks to a couple of articles on the web. I made a load of mistakes so hopefully someone will read this and avoid making the same ones.
First, I had the scripts declared globally, i.e. Dim scriptname As Global.namespace.scriptname. Wrong wrong wrong!
What you need to do is create a ViewState called LastLoadedControl and set this to be the physical path of the control. This will reside in memory and allow you to persist the control between postbacks of the parent form. Then create a Private Sub called LoadUserControl(). This should check to make sure that the LastLoadedControl isn't null, then load the control and attach it to the Panel / Placeholder that you're using to display the controls.
You need to call this LoadUserControl method in the Page_Load event every time. Also, in the method that you're using to drive the user interaction (i.e. the list of scripts to pick from) you need to declare the physical path of the script, set the LastLoadedControl ViewState to this value, then call the LoadUserControl method.
Check out the first example in this blog (it's in C# but easily converted) for a really good example: .
A couple of warnings. First, even though the example above solved my problem, it was causing an error whereby the aspx page was trying to load the same control into the Panel / Placeholder twice and falling over as a result. What you have to do in the LoadUserControl method is specifically set the name of the control otherwise the ViewState of the control (i.e. its values) won't carry across between postbacks. Obviously you can see a scenario where you're creating the same control twice. To get around this you have to remove the control from the Panel / Placeholder every time. The example says to use Panel.Controls.Clear() but this didn't work for me. What I did was check that the Panel had > 1 control, then did Panel.Controls.RemoveAt(1) to eradicte the control and then replace it.
Second warning - some people say to do the control loading in Page_Init, rather than Page_Load. Problem with that is the Page_Init can't reference any Panels / Placeholders etc. so it's a bit of a waste of time.
POSTSCRIPT: just tried loading something into Page_Init in the .ascx control rather than the Page_Load event to stop the value of a control changing every time and it worked. I wonder if it's because I had the Page_Init set to Private before, and now I have changed it to Protected it seems to work ok. My bad.
Identified a problem yesterday whereby the second and subsequent scripts that got loaded had a strange little error - the first server control in the script didn't work on its first event (i.e. click, selectedindexchanged). It would work the second time the control was used - but that's no good for the users.
So I set about trying to solve it. After about seven hours of reading, trying things out and getting really frustrated I did solve it thanks to a couple of articles on the web. I made a load of mistakes so hopefully someone will read this and avoid making the same ones.
First, I had the scripts declared globally, i.e. Dim scriptname As Global.namespace.scriptname. Wrong wrong wrong!
What you need to do is create a ViewState called LastLoadedControl and set this to be the physical path of the control. This will reside in memory and allow you to persist the control between postbacks of the parent form. Then create a Private Sub called LoadUserControl(). This should check to make sure that the LastLoadedControl isn't null, then load the control and attach it to the Panel / Placeholder that you're using to display the controls.
You need to call this LoadUserControl method in the Page_Load event every time. Also, in the method that you're using to drive the user interaction (i.e. the list of scripts to pick from) you need to declare the physical path of the script, set the LastLoadedControl ViewState to this value, then call the LoadUserControl method.
Check out the first example in this blog (it's in C# but easily converted) for a really good example: .
A couple of warnings. First, even though the example above solved my problem, it was causing an error whereby the aspx page was trying to load the same control into the Panel / Placeholder twice and falling over as a result. What you have to do in the LoadUserControl method is specifically set the name of the control otherwise the ViewState of the control (i.e. its values) won't carry across between postbacks. Obviously you can see a scenario where you're creating the same control twice. To get around this you have to remove the control from the Panel / Placeholder every time. The example says to use Panel.Controls.Clear() but this didn't work for me. What I did was check that the Panel had > 1 control, then did Panel.Controls.RemoveAt(1) to eradicte the control and then replace it.
Second warning - some people say to do the control loading in Page_Init, rather than Page_Load. Problem with that is the Page_Init can't reference any Panels / Placeholders etc. so it's a bit of a waste of time.
POSTSCRIPT: just tried loading something into Page_Init in the .ascx control rather than the Page_Load event to stop the value of a control changing every time and it worked. I wonder if it's because I had the Page_Init set to Private before, and now I have changed it to Protected it seems to work ok. My bad.
Tuesday, 26 October 2010
Cross - Domain Scripting and iFrames
I've been doing some work over the last couple of days to embed data from a third party API into the .NET web app front end that we're working on. The API isn't open to everyone - you have to access it via Javascript and it can only be accessed on the server that all the component parts run on. As API's go it's pretty useless when you want to hook into it from somewhere else.
So our javascript guru showed me how to make an app in an iframe talk to the parent app that's hosting the iframe and away I went. I built a .jsp page on the API server that delivers all the data I want and then modified the .aspx page to include some labels to display the data.
I ran into a couple of problems. The first concerns the iframe load time. I originally tried to write some javascript that would load the values from the divs on the .jsp page into server controls on the .aspx page but this failed because the iframe was always the last thing to load and all the server controls saw was NULL values.
The js guru suggested a kind of timer function that would check when the iframe had finished loading before running a script to get the values. But it turned out that the simplest solution was to make the .jsp page populate the values itself - you can make the content of the iframe control what gets written to the screen in the parent as much as you can do it the other (and more logical) way around. In this case the connotation of parent and child is wrong - they're more like siamese twins joined together and able to influence each others movements.
Another useful thing to know is that you can only make two apps on two different servers talk to each other if you suffix the server name in the URL with the name of the domain that they both share. So if my domain is www.markp3rry.com then you will need to set the servers to http://server1.markp3rry.com:8080/ and http://server2.markp3rry.com:8090/ (for example).
There's a heck of a lot of scuttlebut written on the web about this topic so tread carefully. A lot of the examples for extracting information from an iframe in both javascript and jquery script were making me tear my hair out. You have been warned!
So our javascript guru showed me how to make an app in an iframe talk to the parent app that's hosting the iframe and away I went. I built a .jsp page on the API server that delivers all the data I want and then modified the .aspx page to include some labels to display the data.
I ran into a couple of problems. The first concerns the iframe load time. I originally tried to write some javascript that would load the values from the divs on the .jsp page into server controls on the .aspx page but this failed because the iframe was always the last thing to load and all the server controls saw was NULL values.
The js guru suggested a kind of timer function that would check when the iframe had finished loading before running a script to get the values. But it turned out that the simplest solution was to make the .jsp page populate the values itself - you can make the content of the iframe control what gets written to the screen in the parent as much as you can do it the other (and more logical) way around. In this case the connotation of parent and child is wrong - they're more like siamese twins joined together and able to influence each others movements.
Another useful thing to know is that you can only make two apps on two different servers talk to each other if you suffix the server name in the URL with the name of the domain that they both share. So if my domain is www.markp3rry.com then you will need to set the servers to http://server1.markp3rry.com:8080/ and http://server2.markp3rry.com:8090/ (for example).
There's a heck of a lot of scuttlebut written on the web about this topic so tread carefully. A lot of the examples for extracting information from an iframe in both javascript and jquery script were making me tear my hair out. You have been warned!
Subscribe to:
Posts (Atom)