Skip to content

ASP.NET Web Application Development

I know, I was pretty sure I was done with development work in my illustrious career ;).  Then comes along a new project – I dont know if I have the energy to write good posts around this project.

I am reminded already that writing, especially in the public domain is a good brain activity.  Its something that pushs the envelope a little.  Helps to keep you from complacency, which is a big problem for many people.  Stretches you from your comfort zone.  Challenges!  Yes, good good good. But, its also difficult tedious work.  The kind of work that beats you up, spins you around causes you pain and frustration.

So, ASP.NET it is.  I considered the WAMP environment – which is what all my old moodle blogging was about.  But, I was hoodwinked into using the Microsoft suite of tools, AKA ASP.NET.

Fortunately for me, the concepts and ideas don’t change.  How software works does not change.  How DBs work does not change.  How the internet works (HTML, CSS, Javascript) does not change.

What changes?  The tools, the language(s) of implementation.  That’s what changes.  Tool number 1, the IDE.  Im using Visual Studio community editon – the free one.  VS is open source tool with lots of different things it can do.  Learning the lay of its land, a decent sized hurtle.   So many tools and different ways to do things.

There are many frameworks and packages to work through.  The ASP.NET tools and frameworks that I decided on for my project are:

MVC Entity Framework

Razor view technology – which uses a page type .cshtml.  The pages are html, but with c sharp code snippets embedded in the pages.

I choose the MVC pattern because I have used it before and like it.

In my application space, I have the familiar arrangement of folders, including folders for each layer of the application Model, Controller, View.  Each of the view pages is handled by a matching controller.  the controller communicated to the model layer and the classes in the model layer representative of tables in the DB.

Entities often represent tables in the DB.  The ORM EF “Entity Framework” helps with the frequent or common requests of data in the table, specifically a row.  Common CRUD row requests:

  • create
  • retrieve
  • update
  • delete

I ORM when creating a view page for one of the requests includes the HTML form code and handles the actual work of communication with the DB.  I mostly like this, although in the past, I have created this code and looked down my nose at a framework that would do this for me.

I spend a few hrs a day over a couple weeks playing around with Visual Studio, watching and reading tutorials, creating new projects, trying to figure out how I would build the application (the view side of things).  Then I started looking at my DB and what that would look like and how I would represent that in the model layer of the application.

If you wanna learn about ASP.NET, then you have to start developing in ASP.NET.  Ya wanna learn Java? Ok, then do Java.  Over and over and over.  Make those mistakes, retrace steps, try something else, wash – rinse – repeat.

I can see the application from a conceptual level very well.  I can see the distinct parts of it.  The DB, its tables and data, the view files or interface that users will see, I can see people interacting with it.  I can see the requests in the application running through the controllers and into the model interacting with various entities in the system.  Now getting to that vision is the harder part, the part frout with pitfalls and mistakes.

A user makes a request of the application, “show me all the orders for district a”  The request is sent from the application view layer which passes to a related controller which communicates to a model class entity which interacts with the table in the DB.

Crystal clear…..


Finalsite web site project

As we push into the implementation of our new web site, a few thoughts.

Our design phase is almost over.  Three iterations down and approaching the end, where we will “freeze” the design.  Finalsite will bring in a developer to *build out the site.  BTW, the vendor uses Coldfusion, a language I used to develop in ;).

Our site, even tho not build out, has been available to the site admins.  We have been able to log into the site as site level admins and see the skeleton site.  We provided site maps a while back, so when we log in, we can at least see that.  No real content yet and no real look and feel, that comes from the site build out.

I have been working in the constituent manager, group manager, news manager, calendar manager and the posts module.  There are all key pieces of administrative software.  We populated the site using a data sheet.  The vendor supplied this, along with some directions on how to populate the sheet.  I worked with our HR department and obtained current complete faculty information.  Once the date sheet was completed and uploaded by the vendor, we could start to work more with both the constituent and group managers.

The site has a concept of two different logins.  The first is the portal login.  This is for all the staff who are not admins.  We have 1100 staff, of which about 25 are admins.  Admin means content managers or champions.  Most of the staff will access the website and then login to the portal.  The administrators, content editors, will log into a different location on the site.

  • siteURL/login – for faculty
  • siteURL/admin – for content managers – admins

To create admin accounts, we go into constituent manager, find the account and create a second account, and admin account.  That account is linked to the portal account.  Once the admin account is created, it then joins an admin. group.  Finally, we go to the space of page on the website that the group would manage and change the access property from public to the name of the group.

  • Faculty = portal login
  • Admins = site login
  • Admins have a group
  • A page or space of pages has an assigned group

When a faculty logins in, they land on the portal home page.  The portal space tries to alleviate the public site from any kind of staff related information.  One of the goals is to keep employee information off the public site.  Rather – put that in the portal and do not clutter up your public persona with staff information.

If a staff  member is a content manager, then they have two places to log into.  The portal for staff information and the admin to update content on the relevant part of the public site.

The portal users also can create content on the website using the Posts module.  The site admin has to set up Teacher Boards for their group first, then the staff member when logged into the portal can access their teacher boards there.  A board is a space where the faculty member can create web content by using the post module.   I was able to login as site admin go to the Posts area of Composer and specify per group if they wanted Boards.   I was even able to auto generate the Boards.  For example, we have a education center that has 90 faculty members.  I was able to create en – mass, Boards for every member.  Upon completion of this, each of those staff members could login to the portal and access their Board space from their profile.    I then went to the education center space on the public website and created a faculty list, which included an option to show teacher board links.  The faculty list is publicly accessible.

FinalSite prep

I went to a 2 full day workshop last week with our new software Finalsite.  This system is replacing a 10 year old website on Blackboard schoolworld.  Incidently, BB announced
EOF for schoolword effective 1/1/18.

Finalsite – CMS, LMS – web site software.  The prep workshop featured 60 minute presentations on difference managers (pieces of the software).  They showed us how the software worked in a fast detailed way.  We had 6 different presenters over two days.  It was a good experience.

20 Primary take away’s

  1. We have work to do getting the modules – (managers) ready to go.  The have to be feed – prepped, rules established
  2. We need to figure out who will be content managers for different modules.
  3. CM = Constituent Manager.  We need to sync CM with our MS LDAP directory.  BOCES LDAP master – Finalsite CM (slave).
  4. We need to establish groups and start populating them with accounts from CM.
  5. Constituent Manager, E-notify, Media Manager, Calendar Manager, Groups Manager, Composer.
  6. Composer is the tool content managers will us to create, edit web pages and their content. Composer is constantly being updated and improved.  Look at site dashboard Updates for details.
  7. Composer has access to content that is in the modules.  Content is added to the web page via elements – very granular and specific.  elements like content, navigation, calendars, media, people.  As a content manager, you access a lot of site content from the module – elements.
  8. Pages have elements.  Elements have content.  Pages have permissions – among other things.
  9. Pages and elements have settings – look for the gear icon.  Choose the page or the element in the page – explore their options – of which there are many.
  10. That we should look to use the Posts tool and not the News tool – as the News too is fazing out, new development has been in the Posts module.   Teachers who want teacher pages will use Post tool
  11. The Manager tools all have the concept of a dashboard -of course.  At a glance see what, when and who.  Each manager is similar – with dashboard and green action buttons with white text.
  12. fs-actionbuttons
  13. When building content, use vertical layers, not horizontal.  Vertical layers respond better in mobile devices.
  14. Don’t mess too much with the home page.  It has special sauce.  You can change photos in the media manager – or text in a content element or the name of a button….BUT, you cannot change the layout, order, main elements – that would require a work order.  The mentality is do not mess with home page – we worked hard at nailing that look and feel.
  15. When you are in *compose mode in composer – you can hover over page elements and access their properties via pink gear.  Elements like, Search, navigation, content, media, embed – the elements all share common look and feel and some functionality, but also posses unique options.
  16. Some page elements will be shared.  Shared means live in one place and referenced from multiple.  Do not upload things to multiple places.  If something needs to be included in multiple places on the website – then create it once and share it.
  17. File Manager module.  We need to establish a hierarchy of information management.  File manager module is also under development and can expect changes in near-ish future.
  18. Portals are just a concept, nothing magical.  Control access to content in *portals by simply assigning visibility permissions to a group – that have the constituents in them.
  19. We can conceptually separate pages that are restricted to just groups in the site architecture by using a portal file structure like portal/hr or portal/principles – and then keep the pages to be restricted in those folders.  There is nothing different about a page that is visible to the public -vs- a page restricted.
  20. The software modules are continuously in development – via *agile methodology.  The presenters talked about changes in the software and how often it is deployed.  Updates are reported in the admin dashboard.
  21. To sport the nifty sticky navigation – which we want, is additional $.  Our client success manager said he would talk to Shanda about that cost.
  22. We meet our client success manager Jerard Gustafson.  He is our POC once the project is completed.  Jerard and Shannon.
  23. shannon-jerard2
  24. I meet Amy – who will be coming out to visit for a live training.  Amy the FS trainer.  She also went over the site admin. stuff at conference.  She will be training content managers on Composer.
  25. E-Notify – a good tool, should depreciate the list server for Edutech.


What we want from our website rebuild

Well, that is wide open!.  I spoke with my boss yesterday, she gathered her 6 managers and talked a little web site rebuild with them.  These are the things I heard her say.

can we still put passwords on pages that are intended for the public?

the site map we have to give you (thats me) needs to be two tiers?

Will there still be a *site wide search feature?

will we use our network login credentials to log into the private facing content on the website?

can we still keep a quick link to the web email?

should we have a twitter feed?  or what do we think about social media?  Do we really need social media?  If we create social media, who will feed the beast?

we should use pictures of people, who we serve, not things, technology things.

how would all the old content get moved to the new site?  Some would not, its old and irrelevant, some would be restructured, like three pages become one, we would move some, the vendor would move some.  Its a real chance to take things to the curb.  Just like when you move, you make hard decisions about what is moving and what is going.

that our organization would be using mylearning plan for development / training type events – since our districts use this too, we can see their scheduled events while considering our own.  I added that we purchased the calendar module already from our new vendor and that each of the 10 schools in our organization would have their own.  they would still use the calendar to schedule things, events for their schools.


We are in the discovery phase of our project.  We have a couple weeks to produce our first set of deliverables.  Those in the form of – a theme, site maps, images and a design survey.  These things are used by the designer who will mint the site using the deliverables.

Our next meeting in next week, when we are hoping to nail down the top elements of a theme – they have a bunch of existing ones, but we seem to like specific things from a bunch of them, so maybe they will simply build us a new one.  Our designer needs from us ideas, starting points, things we like – so she has things to go with upon initial build.

The day I exported 35 hrs from 7 cameras

Yesterday, I have a request from a big cheese.  Something like this “James, I need to see the interior cameras for building bla”.  After locating the interior cameras and showing them to him via a screen grab, he was able to narrow them down to 7 and the range of time to about 5 hrs.  A total of 35 hrs, 7 cameras * 5 hrs from each.   In my old brain, I though man, that’s a lot of video to export and for someone to watch.  I thought I would be chopping the video up into 1 hr. exports, 5 per camera – for a total of 35 distinct exports.  I worried about the playback of such large videos. That was where I was wrong.  The software dominated the process.

We use Genetec software, with its heavy footprint, in terms of drive space and memory, but, it was the right tool for the job. An impressive piece of software for this task.  Incidentally, I first tried exporting from a camera using the web client, I quickly found that  was not the right tool for the job.

Once I got the hang of the export tool/interface, using the default export format g64 was a breeze.  I was able to easily choose the day and time range for the export. G64 is the default proprietary format for the software and has amazing video compression.

So good, that I was able to create a single export for 4-6 hrs for each camera – each about 75 MB.  How 4 hrs of video can be compressed into 75 MB is pretty impressive to me. The exportation of a 6 hr range from one camera took about 90 seconds and created a 140 MB file.  Impressive.


At the end of this process – I was able to put all the exported video and the player on a thumb drive while using about 2 of 15 GB.

My customer can now either play the exports in his Genetec desktop client or he can use the portable player,  allowing him share with someone else.

The end.


Our security camera software – exporting video

I support our Genetec security camera software.  Today, I was testing my understanding of which cameras stored video and for how long.  We have about 100 cameras in 6 buildings.

One might think that every camera keep its video for at least a short time, but that is not the case here. Some cameras store 30 days worth of footage.  After that, the space is *recycled by the server.  It is expensive to keep 720 hrs of video.   I can request a time range anywhere within the stored data.

To test which cameras were storing, I opened the web client and dragged cameras to the grid and then choose to export from the camera – the system reported no video avail for some of the cameras, while others exported short 1 minute videos.


My takeaway?  Know which cameras store video and for how long.

Results – for James


Managers want this thing, often….

Or is it IT directors, or Admin?  None or all.  Anyway.

We have systems, like most people/organizations.  Those systems have credentials, like usernames and passwords.  Systems no longer are allowed to work in silos – they must, share their data.  The systems want to share their data, they want to connect to other systems.  Systems / software stays healthy and relevant when it connects to other software and shares things.  Fine, lots of standards out there trying to promote rules for sharing things, but to my simple point.

One of my customers was how do you say,  Seduced?  He was tasked by NYS government to do something, saw a presentation on how it could be solved and wallah, sold.  Flash forward a couple months and he contacts me with a question like this

“James can the link in so and so open the security cameras into a view, automatically?”

On further review we notice that his customers would use system a to get information and then system b to view security cameras.  System a makes the user authenticate.  System b also makes the user authenticate.  My customer wants the authentication in system a to also work in system b.    He figures they already logged in over here, why do they have to log in over there?  Its a valid question.  I told him out of the gate that we may not be able to accommodate the request – meaning system b may not have the capability to allow system a to bypass or feed in credentials.  The user of system a will also have to authenticate in system b.

My customer wants to bypass the front door of the house and the need to show proper id for entry.  He wants them to use the back door with a special token gained from system a.  He wants his customer to arrive in the living room, bypassing the door and id check.  No can do.  I tried, I worked with the engineers of system b and asked if we could somehow provide id on the link in system a, that would automatically allow entry into the living room.  Nope.  I get it.  Its a risk.  Software wants to make people authenticate too, especially software that contains cameras.

Moral of the story?

People want shortcuts, ease of use, but systems still require id.