Can you contribute a small change?

Coordinator
Oct 16, 2010 at 11:58 PM
Edited Oct 17, 2010 at 1:13 AM

Here are some simple features that would improve www.bostonazure.org but are not very complex:

  1. Implement http://www.bostonazure.org/firestarter in the Azure version of the site. Currently this is broken - it does not resolve because it is not implemented. Implementation will require creating an ASP.NET MVC View and Controller and deploying some images into Azure Blob Storage. See old (non-Azure) site for ideas of how it used to look (http://bostonazureusergroup.org/firestarter). New site need not look like this, but it is important that there be something at this URL (don't like to break very public links like this), and would like to preserve all the photos.
  2. Image links from http://bostonazure.org/events are broken. Task would be to add them to Azure Blob storage. The images are avail from old site and from Code Plex: http://bostonazure.codeplex.com/releases/view/53388. See old (pre-Azure) site to see how it should look: http://bostonazureusergroup.org/events.
  3. Add an exception handler such that when the Events database is not available, the Events pages do not crash.
  4. Change the "Subscribe" action from changing pages to instead be inline using Ajax (or jQuery) or popup. This is instead of redirecting the user over to Constant Contact.
  5. Simple integration with Constant Contact API to get the event ID for the next meeting to use for the home page. Currently the link (e.g., "RSVP for October 21, 2010 Boston Azure User Group meeting") is manually entered, but would be better to automatically construct it through the Constant Contact web service API.
  6. The home page of the site provides a description of the next event. This is not reusing data from the Events list. One strategy would be a User Control and the ASP.NET MVC Html.RenderPartial approach.

Feel free to add or suggest other simple changes.

 

 

 

 

Coordinator
Oct 17, 2010 at 11:03 PM
Hey Jason - DNS update completed: I created CNAME such that blob.bostonazure.org now maps to bostonazureweb.blob.core.windows.net
 
Also mapped this in Azure portal (per http://msdn.microsoft.com/en-us/library/ee795179.aspx); I verified it in portal (with guid.bostonazure.org CNAME mapped to verify.azure.com) per instructions.
 
Note that other images in the current site map to the raw (non-CNAME-mapped) blob address. Perhaps we can normalize those too in the future.
Also, if you create a utility to do the upload, feel free to stuff the source code into the Tools folder under Boston Azure Project. The Tools area exists, though currently there are no entries in it. It is a sibling to the web site.
Cheers,
-Bill
On Sun, Oct 17, 2010 at 6:36 PM, jason at jason haley com wrote:

Bill,

For the images not showing up or needing to be added to blob storage – have you pointed a cname at the blob url for the account like mentioned in here ->

http://msdn.microsoft.com/en-us/library/ee795179.aspx 

The images want a url like: http://www.bostonazure.org/blobs/brian_lambert_presenting.jpg 

Seems we’ll need a cname pointed at the blob url for the account, then we can create a container named ‘blobs’ and add the images to that container.

If you take care of the cname, I can take care of the container creation and uploading of the images to the container (I’ll write a little utility for it). 

j

Developer
Oct 18, 2010 at 11:24 PM

Team,

I will look into numbers 1 and 3.

Thanks, Arra

Coordinator
Oct 21, 2010 at 2:37 PM

I will take #6. Great start. - Nazik

Oct 21, 2010 at 7:58 PM

I'd like to help out.  I can't go to the meeting tonight (10/21/2010) unfortunately.  Thus, I will look at #4 and #5 in the next couple of days but I'm not excluding anybody else from working on them.

Developer
Oct 29, 2010 at 8:49 PM

Team,

I believe I have #3 pretty much wrapped up. I implemented some exception handling and logging for the events repository using the Enterprise Library Logger Block and the Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener as the listener type. This is a pattern we can reuse across the website to log events to the built in diagnostic framework of Azure. In order for this log to be persisted I configured the Diagnostics object to commit the log information to the WADLogsTable (local table storage) every five minutes. This seems to be working pretty well. 

Couple of questions I had before I check this in:

1. How do we want to handle the references to the Enterprise Library? Just checkin the dlls in the bin folder or require everyone to download enterprise library and reference it on their own? I am accustomed to not including the dlls in the bin and just the reference. But anyway is fine with me.

2. Since we are logging exceptions and system information to a Diagnostic monitor that is only committed every five minutes we will not see these events in the live Trace of the web role. Should we create an extension of the Logger block to log a trace event and to the Diagnostic log as well?

Let me know your thoughts.

Thanks

Arra

Coordinator
Oct 30, 2010 at 12:41 AM
Hey Arra - fantastic! Regarding #1 - there are always things external to the code on which we have an implied dependency - Visual Studio being an obvious example. Another tough one will be unit test framework. That said, I think requiring future devs to all separately download and install EntLib may be more of a hassle than we need (not big enough payoff) versus just stashing the needed binaries in source control. Regarding #2 - interesting idea - I am curious what others think... Of course, you can feel free to proceed: we are all about "gently over-engineering" our system based on individuals' interests. Cheers, -Bill Sent from my Windows Phone
Developer
Nov 1, 2010 at 1:25 PM

I agree with your response for #1. As far as #2, I wanted to bring it up because I am less familiar with the Ent Lib Logging Block and the Windows Azure Trace tool. After implementing it I expected all events to go to the web role diagnostic window and then just be dumped into table storage at a 5 minute interval. I think it would be advantageous to see live error logging along with the ability to store the logs in table storage so we can view them at anytime. I will look to implement a custom class to do this. - Thanks, Arra

Developer
Nov 2, 2010 at 1:25 PM

So I had a little free time and I was looking into the question I had for #2 and it seems reading up on the differences between the development app fabric and the actual cloud has answered my question. http://msdn.microsoft.com/en-us/library/ee923628.aspx In this HOWTO it describes that;

"In the development environment, logging information is written to a role instance’s output window in the development fabric user interface, as well as captured by Windows Azure Diagnostics. In Windows Azure, logging information is not directly visible, but may be transferred using the Windows Azure Diagnostics API to a table in a Windows Azure storage account, at which point you can work with them in whatever manner you prefer."

This leads me to believe we will only get to see debug information that we transfer to table storage in the cloud anyways. Perhaps I will add an environment specific flag that will let us know when we are in a development environment and make a separate Trace logging call for these scenarios.

As far as the firestarter page I have uploaded all the images to blob storage and have the page resolving. I plan on implementing a jQuery image gallery tonight and then checkin the code. Cheers, Arra

Developer
Nov 5, 2010 at 2:55 AM

Checked in changes for #1 and #3. Implemented firestarter page using blob storage for images. Implemented some error logging and exception handling for the events page and for the website in general. All logs are dumped to table storage every 5 minutes.

Coordinator
Nov 13, 2010 at 9:56 PM

Hello Bill,

I am working on #6. I need some clarification.

Per requirement for this item as I understand, it is to create a user control to retrieve data from the database and display it in the front page.

I see number of fields in the database namely:

eventid

title

description_html

featured_html

Start_utc

End_utc

I am assuming I should only be concerned with the fields title and description_html  for now to be used by the user control. For the  title field, I am assuming I will have to wrap a html snippet around it. I will also show the raw html from the description_html field as the name of the field suggests. The start_utc can be used to sort events. The other fields I am assuming is for future projects or let me know otherwise.

Let me know which area of the front page should be covered by the user control. I have created a jpeg for you to convey my assumptions. I have also created a SketchFlow site for the front page if you prefer to indicate the areas on that site.

If my assumption(s) are incorrect then please reply in this thread or give me feedback via the Sketchflow site.

The jpeg can be found here: http://www.nazikhuq.com/bostonazureusergroup/BAUGFrontPage.jpg

SketchFlow is located here: http://www.nazikhuq.com/bostonazureusergroup

If you prefer sending feedback via SketchFlow then there is a 5 min video covering SketchFlow feedback: http://expression.microsoft.com/en-us/ee426899.aspx

Thanks,

-          Nazik

Coordinator
Nov 14, 2010 at 12:50 AM

Hi Nazik,

(Reposting since the prior posting contained HTML tags in the text. I had done that on purpose - since I was talking about HTML - but they did not get escaped properly for some reason. So trying this on the CodePlex site directly. Wish me luck...)
 
First of all, thank you for taking the time to give it the thought it deserves. Also, at some point I would be interested to hear more about your success in using SketchFlow to discuss design questions like this.
 
So... Great questions... this is actually a little tricky.
 
If you look at the Events page (http://www.bostonazure.org/Events/Upcoming), you will see four columns showing Title (title), Description (description_html), Starts (start_utc), and Ends (end_utc). So the key data column is really start_utc to figure out which meeting we are concerned with (by using knowledge of today's date, figure out which of the meetings in the database is in fact the next meeting) - then for that meeting, we want to display whatever is in description_html.
 
We need some ground rules around what can be stored in description_html - otherwise, the home page may need to make too many assumptions about it, coupling them together too tightly. So let's assume that description_html is essentially single <div> tag (and can change the current data in the database to match this assumption) - the current description_html is a <ul>, which isn't bad either, but I think assuming a single <div> will be cleaner. This makes it a self-contained display object for embedding among the home page's HTML stream.
 
FUTURE CONSIDERATION: I think the underlying data should not actually be a blob of HTML though. It should be more structured - maybe a row for each timed lined item in a meeting. For example, there could be a row that described the main speaker coming on at 7:15, finishing at 8:15, and could include separate fields for a topic description, speakers, and such. There could be an additional row that says Boston Azure Hack Time is 6:00-7:00. Then from this structured data we could generate what is now in the description_html content. It would do this by pulling all the meeting topics for that meeting, sorting them by start time, applying appropriate markup (like embedding each time slot into a <li> within a <ul> like the current home page does). But we don't need to do this now. For now, let's assume this is pre-baked in a single <div> tag that lives in the database in the description_html column - exactly what we have today. (This may actually become important sooner than later - we have a new site (visual) design in the works that is a little more sophisticated.)
 
Make sense?
 
Furthermore, the data access pattern is similar to what is happening in the existing class BostonAzureEventRepository. Consider adding a method to this existing class to retrieve the next meeting's data - something like FindNextEvent()? - which could do the date logic to find the "next" one (via a LINQ query, perhaps), and return its corresponding Event object. Then in the future if we ever change the underlying data structure (to, say, Table storage, or just a different SQL schema) then we won't have to change any display-oriented code accessing it.
 
Finally, from an encapsulation point of view for insertion into the page itself, a user control might be a reasonable option (.ASCX) - rather than inlining code directly - but you may have other fine ideas for implementation...  There may also be handy MVC 2 (or 3?) constructs I am not aware of that may be more elegant.
 
One more thing - the database schema specificies start_utc as the start time of the meeting - this is actually not UTC, it is Local time. Yeah, that oughta be refactored at some point. :-(  This probably won't bother you much, but be careful your date logic assumes local rather than UTC time...
 
Keep them questions coming!
 
Cheers,
-Bill

Coordinator
Nov 14, 2010 at 1:00 AM

And Nazik - one part of your question I may not have answered fully... There is the main body of text on the home page that contains most of the information about the upcoming meeting. That was most of what the prior reply was about. But you'd also asked about the header text at the top of the home page that reads something like "The Thursday November 18, 2010 meeting of the Boston Azure User Group is fast approaching!" - what about this?

This is not what is in the "title" column in the database, as you may have figured out by what shows in the first column on the upcoming meetings tab (http://www.bostonazure.org/Events/Upcoming). So this database field is probably not useful on the home page.

But the date of the next meeting also appears in a couple of places on the home page. And this text is not continguous with the other text displayed (description_html) - so it probably needs a different solution. So what to do?

What about an easier, "mini" version of the approach for displaying the description of the next meeting?

Note that the goal is to change the underlying database - but NOT have to redeploy the site. So handling these other couple of dates would help that a lot.

Note also that the date in the Registration link is also related to using the Constant Contact API to figure out the registration link for the next meeting...

HTH.

-Bill

Coordinator
Nov 14, 2010 at 12:36 PM

Hi Bill,

I agree with your idea to have a single <div> in the description_html for now to prevent tight coupling it with the home page.

In the immediate future, my understanding from reading your reply is most of the event related HTML will be pulled in from the description_html of a single row using the using a user control. This row will be identified by the latest date in the start_utc column.

In the future, we will have several rows related to an event as you described, have a user control pull data from those rows, decorate it with HTML and merge(what is now in the description_html content). That future is not far off.

I agree with your assertion, from an encapsulation perspective, that we not use inline strategy to show event information in the home page. So I am considering using an user control(ascx) with HTML.Rederpartial in the home view. Razor looks promising with its simplified constructs and may look in to for the future enhancements.

Cheers,

- Nazik

Coordinator
Nov 14, 2010 at 12:51 PM
Re: "... most of the event related HTML will be pulled in from the description_html of a single row using the using a user control. This row will be identified by the latest date in the start_utc column." Exactly.

RenderPartial seems like a fine idea. And Razor may well be in our future too...
On Sun, Nov 14, 2010 at 8:36 AM, nazik <notifications@codeplex.com> wrote:

From: nazik

Hi Bill,

I agree with your idea to have a single

in the description_html for now to prevent tight coupling it with the home page.

In the immediate future, my understanding from reading your reply is most of the event related HTML will be pulled in from the description_html of a single row using the using a user control. This row will be identified by the latest date in the start_utc column.

In the future, we will have several rows related to an event as you described, have a user control pull data from those rows, decorate it with HTML and merge(what is now in the description_html content). That future is not far off.

I agree with your assertion, from an encapsulation perspective, that we not use inline strategy to show event information in the home page. So I am considering using an user control(ascx) with HTML.Rederpartial in the home view. Razor looks promising with its simplified constructs and may look in to for the future enhancements.

Cheers,

- Nazik

Read the full discussion online.

To add a post to this discussion, reply to this email (bostonazure@discussions.codeplex.com)

To start a new discussion for this project, email bostonazure@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Coordinator
Nov 14, 2010 at 2:42 PM
codingoutloud wrote:

And Nazik - one part of your question I may not have answered fully... There is the main body of text on the home page that contains most of the information about the upcoming meeting. That was most of what the prior reply was about. But you'd also asked about the header text at the top of the home page that reads something like "The Thursday November 18, 2010 meeting of the Boston Azure User Group is fast approaching!" - what about this?

This is not what is in the "title" column in the database, as you may have figured out by what shows in the first column on the upcoming meetings tab (http://www.bostonazure.org/Events/Upcoming). So this database field is probably not useful on the home page.

But the date of the next meeting also appears in a couple of places on the home page. And this text is not continguous with the other text displayed (description_html) - so it probably needs a different solution. So what to do?

What about an easier, "mini" version of the approach for displaying the description of the next meeting?

Note that the goal is to change the underlying database - but NOT have to redeploy the site. So handling these other couple of dates would help that a lot.

Note also that the date in the Registration link is also related to using the Constant Contact API to figure out the registration link for the next meeting...

HTH.

-Bill

 I am also thinking of implementing your "mini" solution using HTML.Partialrender in the view. I am assuming we have to create a something similar for "Constant Contant" link for the next meeting and the integration is something George is looking at. - Nazik


Coordinator
Nov 14, 2010 at 3:59 PM
Re: "I am assuming we have to create a something similar for "Constant Contant" link for the next meeting and the integration is something George is looking at."

Exactly. The solution for the next meeting registration link would also need to worry about the possibility that the registration page is not yet established (and should say "coming soon" or similar).

While distinct, perhaps could share "find me the date of the next event" code.

Sent from my iPhone

On Nov 14, 2010, at 10:43 AM, "nazik" <notifications@codeplex.com> wrote:

I am assuming we have to create a something similar for "Constant Contant" link for the next meeting and the integration is something George is looking at.