Eric Polerecky

Or just what I coded to I could lean how to use facebook connect…

Background

When facebook connect was released I wanted to code something to see how it all worked. I wanted to code something I could prop up relatively quick. Partly due to my lack of time but also because I have not released one single piece of software all year! I decided that, since I was just hopping into the land of twitter and I found it complicated to manage my twitter status and my facebook status, that I would write a small app that would allow me to update the status of each site either concurrently or independently.

Specifications

• support facebook connect : (100%)
• local uid/pass system : (80%)
• update facebook status : (100%)
• update twitter status : (100%)
• update local status : (100%)
• private status updates : (100%)
• support tags : (100%)
• support date/time updates (past, present and future) : (70%)
• provide meaningful statistics : (30%)
• support a public profile/time line page. http://pinggr.com/detroitpro : (50%)
• mobile version : (10%)
• simple API : (0%)

Out of scope

• Clone twitter
  • I am thinking that it would more sit “on top” of the status update services.
• Full “router” support aka: act like ping.fm

Features I would like to add in the future

• Twitter style reply and dm
• openid support
• more status sites

development, facebook, jQuery, pinggr, twitter

In the past, when building small web applications with up to a couple concurrent users, I’ve placed the database on the same system as the web server. Blasphemy!!!…not really. You see, knowing that database systems will entirely consume their allocated memory allows for clear capacity planning.

There are many factors that need to be taken into consideration when designing an architecture and for the sake of this post lets just say that:

• This system does not require a ridiculous amount of memory
• This system does not require HA

And really, while every project sponsor will tell you that their project requires the most powerful server ever built and for the sake of humanity can never go offline again, most web applications don’t require all that much memory…and the fate of the company is not dependant on 100% uptime…just check the SLA.

So what does this all have to do with “Content Segregation”? Oh, and WTF is “Content Segregation”?

Ok, ok, just one more paragraph to provide context.

Large web applications with high concurrent user counts will commonly separate not only content types across systems but also application modules. For example, there might be a small web server cluster for images or a separate group of servers for the account management modules (login, register, profile). These practices are commonly accepted and I couldn’t agree with them more. Its just that most of the applications I am involved with don’t require this type of advanced architecture even though the project sponsor would have you believe otherwise. These, not the large web applications, are those we need to discuss..

So what does this all have to do with “Content Segregation”? Oh, and WTF is “Content Segregation”?

Until recently performance and availably have been the only reasons I’ve recognized to separate content across physical servers. That is until just very recently, in a meeting of the minds it was stated, as fact, that “Items of content type X are data and should be stored on the database server”

WTF? Let me clarify, not IN the database, but on the database server file system..

Ok, I have my head around what you are saying, I understand that your an advocate of Content Segregation, I just don’t understand why, but I can tell you why not.

1. Performance

Database servers are commonly separate physical systems for performance reasons. The DB server should not be a dumping ground of user generated content. It might seem silly but there is a chance that you might really use the SQL server for something that requires its full power. Maybe some form of analytics and when that happens you need to have the available power.

2. Slippery Slope

I truly hate this argument but it fits so perfect into this context. Its not so far of a leap to go from storing images on the database file system to storing images in the database.

SQL, development, technology

Dojo, development, jQuery

This is how I take advantage of dojo when developing an application that uses the toolkit.

First, in the past few months most of the applications I developed have has sparse use of JS with one major exception. Each application has an main “application page” where a bulk of the action takes place.

My current project is a large mapping application similar to maps.google.com or maps.live.com. The application instantiates with a large map and a variety of tools that users can use to generate reports based on the underlying map data. There are ancillary pages for help, sitemap, contact, etc that do not require the amount of JS the map interface requires.

Separation

I create multiple JavaScript files, one XXXX.js and the other XXXX-app.js. The app.js file is only included on the application specific pages.

Note: during development I will create separate JavaScript files for major functionally but combine them before moving to production.

Includes

I try to only include the app.js on the application page.

Onload

   1:   

   2:  function init() {

   3:      app_name = new app_name();

   4:      app_name.postCreate();

   5:  }

   6:  dojo.addOnLoad(init);

app_name

dojo.declare is my friend..

   1:  dojo.declare("my_app", null, {

   2:      _date : '',

   3:      schedule_success : 'Scheduled',

   4:      store_dealer : null,

   5:   

   6:      constructor: function() {

   7:      },

   8:      postCreate: function(){

   9:          var page_body = dojo.query('body')[0];

  10:          switch(page_body.id){

  11:              case 'index':

  12:                  this.index.init();

  13:              break

  14:              default:

  15:                  console.log('default');

  16:              break;

  17:          }

  18:      },

  19:      index: {

  20:          init: function(){

  21:              dojo.connect(dojo.byId('dashboard'),'onclick',function(){ dijit.byId('tabs').selectChild('tab_dashboard'); });

  22:              dojo.connect(dojo.byId('export'),'onclick',function(){ dijit.byId('tabs').selectChild('tab_export'); });

  23:          }

  24:      }

  25:  });

Dojo, development

Typing the phrase “naming conventions” makes me feel ill. They have always been someone of an objective topic and a topic that has ALWAYS lead to intense debate. Well, I hope that my little foray into code analysis has lead me to stumble upon a clear concise description for ASP.NET naming conventions.

I ran the new release of FxCop against one of my projects today and came across a few, 1504 to be exact, messages about incorrect naming conventions. Ha!, Like there is a correct way to format your code…wait…what Microsoft thru the error…hmm…maybe someone should check the error description.

Update: The error log is from a clients project, I do not have control over naming standards with this particular client.

Type, namespace, and member identifiers are Pascal-cased.

Parameter identifiers are camel-cased.

Two letter acronyms within these identifiers should be upper-cased, for example, use System.IO instead of System.Io.

Acronyms of three or more letters should be Pascal-cased, for example, use System.Xml instead of System.XML.

The pascal-casing convention capitalizes the first letter of each word, as in BackColor.

The camel-casing convention formats the first letter of the first word in lowercase and capitalizes the first letter of all subsequent words, as in backgroundColor.

Although it may be common practice for some two letter acronyms to not be fully capitalized, violations of this rule should not be excluded for this reason. For example, ‘DbConnection’, is common but incorrect; use DBConnection.

A violation of this rule might be required for compatibility with existing, non-managed symbol schemes. In general, however, these symbols should not be visible outside the assembly that uses them.

development