Saturday, November 28, 2015

two thoughts on patterns that came to me during a Black Friday car trip

The "Repository" pattern for which a name could not be suggested here is really just an example of the Factory pattern as best as I can tell. This serves as ammunition to boost my assertion methinks. Also, this problem of not wanting to have testers retest working code could perhaps be alleviated in the OCP purist paradigm that few of us really wrap our ways around.

Perhaps this isn't that clear. I write for a second time today, having slept on what I wrote above. This suggests that Eric Evans thinks that there is a difference between factories and repositories in that repositories get the data and then the factories compose the data downstream in a second step. I guess if I were not using NHibernate and I were using a stored procedure to grab data in a repository, the dataset would then be run through a factory to cast it to a domain object. Moreover, I began feeling self-doubt about what I wrote above out of realizing that saves and updates to objects don't necessarily return much from repositories and thus might break with the whole factory notion. Hmmm... you are still going to a repository to get an object that you should not just new up cowboy-style outside of the repository so it really feels like this is functionally a variant of the factory pattern with the fact that you can hand stuff back in really just meaning that the "factory" itself may be tweaked. Assuming an onion architecture, you ought to be able to pull all database interactions out of your repositories and replace them with POCOs stored in session or static state or the cache or something and have all the unit tests still pass, and then the only differentiation from a purist factory pattern would be that the underlying state may be tweaked. We are not supposed to care from the outside looking in how this external dependency does what it does, we just call methods on it. As suggested here, we are asking for objects we dare not instantiate and thus the similarity is strong, repository pattern to factory pattern that is, even if repository and factory mean two different things to Mr. Evans as standalone terms not leading the word "pattern."

YUI

The Yahoo! User Interface Library is yet another JavaScript toolkit. It is discontinued. I think it is a would-be rival to jQuery and Dojo.

Friday, November 27, 2015

double pipe symbol operator in JavaScript

Not unlike the null coalescing operator in C# this gives a failover for an assignment should the thing being assigned be null. For example, while this code will throw up a 4 in an alert it would give a 5 if the contents of the "four" variable were falsey instead of 4...

var four = 4;
var five = 5;
var whatever = four || five;
alert(whatever);

 
 

It's like the wacky double ampersand operator in JavaScript only much less wacky. This thing actually makes sense when you read the code.

Thursday, November 26, 2015

the product company versus the consultancy

A successful SaaS model product company will have high margin profits from recurring revenue and this more than anything else will make it a good place to work. The day to day slog at a successful tech consultancy will be a lot tougher but will attract top talent and ultimately provide more opportunities to learn and a greater diversity of things to learn. The diversity comes from a greater number of greenfield applications (in lieu of extending what already exists) and this is the thing that draws in the heavy-hitters too. And yet, if you ever want to get past the flashing lights and inadequacy of upkeep to really work on a business problem and understand a domain, it will happen at the product company.

Wednesday, November 25, 2015

background-size: cover; causes the "Aw, Snap!" Google Chrome error when colliding with the "All" button in ASPxGridView grids for DevExpress.

Stretch a background image across the background of your web site with the "cover" trick. Then, go to one of your paginated lists. Now, scale the list up to show ten thousand records. Watch Chrome start to whimper. Fail!

 
 

Addendum 11/30/2015: max-height: 3000px;

...is the solution for this problem. The number doesn't have to be 3000 exactly. You get the idea, right?

 
 

Addendum 12/1/2015: Honestly, a better way to approach this is to have a setting like so in DevExpress' paradigm...

VerticalScrollBarMode="Visible" VerticalScrollableHeight="600"

 
 

The problem with the CSS height setting is that if you apply it to a body tag, then the ASPxGridView will expand over or, more likely, under your footer. You may hack around this by trying to put a div inside of the body tag that holds the background image, but that's really "rolling your sleeves up" work that might just be "too much" you know? Move the VerticalScrollBarMode setting to the C# code behind to make it condition! Observe:

private void ToggleVerticalScrollbarVisibility()
{
   var count = ReportGrid.GetCurrentPageRowValues().Count;
   if (count > 21)
   {
      ReportGrid.Settings.VerticalScrollBarMode =
            DevExpress.Web.ScrollBarMode.Visible;
   }
   else
   {
      ReportGrid.Settings.VerticalScrollBarMode =
            DevExpress.Web.ScrollBarMode.Hidden;
   }
}

 
 

I called out this at the ReportGrid_CustomSummaryCalculate and ReportGrid_CustomSummaryCalculate events which were assigned like so on the C# side:

ReportGrid.CustomSummaryCalculate += ReportGrid_CustomSummaryCalculate;
ReportGrid.PageIndexChanged += ReportGrid_PageIndexChanged;

temporary session states

These are rows in a database table somewhere which are the authentication standard for an application where traditional sessions cannot exist, i.e. ASP.NET Web API-driven applications. When attempting to do anything the user must hand in the guid for a row and the row must be found. This, yes, means that the rows must be cleaned away periodically (in short periods) by a background process least they linger for too long and that it is probably wise to hand in a second guid for a user's ID also so that attackers cannot easily play guess-the-guid. Perhaps the two guids are just a part of a greater packet for communication wherever applicable. Such packets would take different shapes for differing functional roles in different API calls. The initial log in of a user would have to create a record and hand back to the user the id for the session.