Skip to main content

Kyle Szklenski

Go Search
Infusion Blogs - Beta
  

Other Blogs
There are no items in this list.
Infusion Blogs - Beta > Kyle Szklenski
What's with UX these days?
The UX team here at Infusion is pretty good. Lately, I've seen a lot of terrible stuff coming from other companies' UX teams. I'm surprised that anyone can get away with this.

A recent website I visited made it completely non-obvious which header went with which paragraph. This made it very likely that the user just downloads the wrong item (the paragraph was a description of the item being downloaded).

There's also those people who are throwing common sense into the garbage. An example that I just saw recently is a big drug store chain which has a branch right near my house. I swiped my CC, and the screen on the machine flashed red. I immediately thought, "Damn, it didn't take. Swipe again." So I did. It flashed red again. I read it closer, and the red actually said something along the lines of, "Save 15% on tissues!"

For one, the credit card swiping machine is NOT the place for advertisements. More egregiously though, you should NOT flash RED if you're going to be offering something after they swipe their card, which is in and of itself a stupid idea. Red is the universal color of, "Stop!" And often, "Error!" Finally, their entire store was decked out in red stuff. You know what the other universal thing that red stands for? Anger. It's been statistically shown that red things make people angrier. What store wants people getting angry in their stores?

In conclusion, don't throw common sense into the dust bin when building a UI. Common sense and a little research (even a LITTLE would have stopped them from making the screen flash red, methinks) provide a great fundamental basis for most strong UIs.
A design thought
Hey again. Sorry it's taken me so long to post! I've been quite busy with many different projects.

While redesigning a few things in my head, and thinking about how effective decoupling leads to cleaner systems, I thought about a possible design principle that I'm going to try to follow from now on. I call it the Least Side Effects principle.

The Least Side-Effects principle is: When a piece of your system is going to have a side-effect, abstract that part into an interface and have a mock/dummy implementation that does NOT produce the side-effect, but does some appropriate action anyway (e.g., in almost every instance I can think of, logging it to the hard-drive showing what the appropriate side-effects would be if they were carried out is sensible).

At first, this might seem trivially obvious, but there are some places I've seen it crop up that I hadn't really thought about before. In one project I've worked on, we had to email people when certain things happened in the system. We had no way to test if that code was working, so I made a simple IEmailService interface and made a dummy impl. that logged it to the hard-drive. That let me realize that there was something wrong with the email I was sending, and I was able to fix it without even having to actually send any of the stakeholders emails.

This is obviously really useful for testing purposes as well. I'd consider renaming this principle to the dImpl idiom, if anyone was interested. This is based on the older pImpl idiom (pronounced "pimple", whereas this would be "dimple") - for dummy implementation. But it allows different dummy implementations that are much more easily testable as well, even if only by inspection.

I hope this principle helps you!
The SharePoint Object Model. . .of Doom 1

Edit: This is incredibly long with code, and the code is misformatted. I will be reformatting it tomorrow.

I'm going to be writing a long series of posts about the SharePoint object model. This is so others can start learning the model and understand how not to make some of the common pitfalls right away.

First off, SharePoint's object model is very, very deep. You can do a lot of stuff with it and it can seem overwhelming. However, the basics of it are very simple and awesome - that's what I love about it. For example, to query a library is incredibly easy, which makes it trivial to write a one-off app to extract data or statistics from your libraries/lists. Some one-off apps are much harder to write than others, but with the appropriate tooling, I don't think much of anything is impossible in SharePoint, so that makes it powerful.

I'm going to start this series of posts with just that - querying the data to get information back. I'll list the basic objects involved and how to combine them into a coherent program to gather information.

 

Basic objects:

  1. SPListItem - one of the most basic objects in the SP object model; represents any piece of data stored in a list (and by association a library); can be used to get information from, or store information to, any list/library.
  2. SPList - the object which represents a list; is a parent of SPDocumentLibrary; most of the time, work with SPList objects when needing to query data.
  3. SPQuery - query object; uses CAML to shoot a query off to a list; combined with spList.GetItems(queryGoesHere) to get a collection of items meeting the CAML conditions present in the query; I will not be explaining CAML, but you can learn about it all over the place online, and it's quite trivial to pick up.
  4. SPListItemCollection - the collection of objects returned from a query; can be iterated over, i.e. can write foreach to do something to each SPListItem contained therein.
  5. SPWeb - the website which contains a list you want to query; in most cases, must be disposed; see best practices for disposing objects; is required for most basic SharePoint object model-related work.
  6. SPSite - the site-collection in which the SPWeb object can be found; must also be disposed; is required for most basic SharePoint object model-related work.

So let's just jump right in. Obviously, in order to do this, you have to have the appropriate SharePoint version installed on your computer.

First, make a new test project. Be sure to add a reference to Windows SharePoint Services so that you can import and use all of the objects above. Here is some code:

using System;

using Microsoft.SharePoint;

namespace SampleSharePointObjectModels1

{

class Program

    {

static void Main(string[] args)

        {

// Using "using" here makes it so we don't have to worry about disposing

// these objects directly, even if an exception is thrown inbetween.

using (SPSite site = new SPSite("http://someSiteCollectionUrl"))

            {

// The URLs I'm using obviously won't work on your computers.

// They are fake and somewhat cheesy.

using (SPWeb web = site.OpenWeb("siteRelativeUrlToSomeWeb"))

                {

// This isn't always the best way to get a list, but it's by far the easiest.

SPList someList = web.Lists["listName"];

SPQuery query = new SPQuery();

// If this looks somewhat like XML. . .surprise!

                    query.Query =

"<Where>" +

"<Eq>" +

"<FieldRef Name='someFieldName' />" +

"<Value Type='someValueType'>someValueToCheckFor</Value>" +

"</Eq>" +

"</Where>";

// The following is optional, but will make the search ignore the folder structure.

// In order to also get folders, if necessary, use RecursiveAll. In order to search

// at the base level, there's no need for a scope at all.

                    query.ViewAttributes = "Scope='Recursive'";

// If you know how many results SHOULD be returned, or if you want to page through

// the results, use a RowLimit. This will prevent the database from returning a

// potentially dangerously large number of items.

                    query.RowLimit = 20;

// Gets the list of items based on the query

SPListItemCollection someItems = someList.GetItems(query);

// Just to get rid of redundancies

const string someColumnName = "someColumnName";

// A simple iteration over the list - [] is the indexing operator, which can be used to get a property from the item,

// i.e. the value of some column.

foreach(SPListItem item in someItems)

                    {

Console.WriteLine("For the item named " + item.Name + ", " + someColumnName + " is equal to " + item[someColumnName].ToString());

                    }

                }

            }

        }

    }

}

 

And that's the basics! If you want or need help, feel free to email me at kszklenski@infusion_NO_SPAM.com. Obviously, remove the part about no spam.

Quickie SharePoint Extension Method
public static void BuildWhereTextQuery(this SPQuery query, string fieldName, string fieldValue)
{
query.Query = "<Where><Eq><FieldRef Name='" + fieldName + "'/><Value Type='Text'>" + fieldValue + "</Value></Eq></Where>";
}

This has made it so that writing a Where Eq CAML query is ridiculously simple, and there's no need for U2U's heinous StringBuildering.
On Pair Programming and Speed Kills
I'd like to write another post about the Bob Martin post previously mentioned. In it, he discusses mainly that hacking out code without even considering design or quality is gonna put your project in the toilet faster than Indian food. He didn't say it at all like that - he's not that crude. But that was what he meant, I think. :)

I mentioned that I think test-driven design really helps reduce speed. In a comment there, I also mentioned that tests really help reduce the friction between classes, and I basically explained how I think that comes about in the previous post.

In this post, I'd like to talk about pair programming with respect to speed. I think with pair programming, you can actually increase your speed quite a lot, and still code as well, and here's the controversial parts. . .you can do that even without writing unit tests. This is based on experience with my current project.

My friend, colleague and SharePoint mentor, Hari Padmanaban, and I occasionally go to the Infusion offices here in Boston, and instead of working on our individual pieces of the project never talking, never joking, etc, we just sit together and code out one of our pieces really well. We can go very fast, and each of us is smart enough to see where one thing the other person writes is going to fail. This is like our test (of course, with SharePoint, it is a lot harder to unit test, but that's not really relevant here). And because we're both good enough to do this, we can increase our speed quite a lot, as well as our quality. Not only that, but working with Hari is incredibly fun!

I would say, however, that pair programming + unit testing = epic win. The two combined, even when just in the hands of bad programmers who care, or just average programmers, can produce systems of real elegance, design, and beauty. That's all I really have for this post, as it's late and I'm really tired! Good night!
TDD is not about the tests
I thought a somewhat strange thought the other day. I realized that test-driven design isn't really about the tests. Test-driven design is about the interfaces between classes. I don't mean the interface construct, but rather the way that classes interact with each other. Let me explain.

When you write a test in TDD, what you're really doing is designing the functions that a class should contain in order to be maximally usable, but minimal. What I mean is that it should have the functions it needs to be used in the appropriate scenario(s), and not more than that. It should have enough functions to clearly define how to use that class, but not so many that it becomes impossible to know which ones to use in order to accomplish its task.

I thought of this post after reading a post by Uncle Bob Martin, entitled Speed Kills. I realized that writing tests first automatically slows you down and makes you think about it. That's what it is - you have to THINK before you CODE. It's idiotic to just sit down and start hacking out code. You are guaranteed to produce shoddy code when you do that. And what's interesting is that writing a test first in order to figure out what your class interfaces are going to be doesn't really slow you down that much - it just makes you think about what the crap you're actually writing. Sure, you can be a hacker and write a test first and still hack out a piece of garbage, but it seems very unnatural to me, and indeed much less likely to be the case. The very act of having to do the extra work of writing the test naturally slows us down and makes us think of a good class design.

But it's not only THINKING before you actually write code. Writing a test first helps you to literally figure out what a class needs to do and what it needs to interface with better than just thinking about the problem. No one is infallible, after all, and so if we just THINK about how to code something, it's quite likely that we'll miss some little detail. But if we're first writing some little piece of code which actually uses our classes, we're much more likely to say, "Hey, duh. I can't do it this way or it'll couple it to the UI when it should not be." (Or what have you).

In my next post, I think I'll touch on pair programming and how it helps us slow down as well. Thanks Bob Martin, for Speed Kills, and for calling out the Stackoverflow folks.

Pax,
K
Quick post. . . I, I'm still alive.
I've just been incredibly busy at my current project. I've for all intents and purposes taken over the paper pushing for this project, which I've always been pretty good at due to my extensive experience with educational grants and such.

For the helpfulness of this post, I'd just like to point out something very simple: Use of the "interface" construct in C# (or pure virtual interface, in C++ terms) can completely decouple two pieces of a system, making the two parts (the consumer and the part itself) completely separate from each other. This is incredibly useful, and makes it so you can, say, call a function using a different implementation of an interface, one that (say) doesn't use a database. This can open up Test-driven Development for you in ways that you might never have thought of before, because you can just mimic various things and use the interfaces as dependencies, rather than the class implementations.

Pax,
K
Gateways to the future. . .and SharePoint.
Lately, I've found myself writing a lot of different gateway classes. These are classes that act as the interface with a a layer, or some other architectural entity. For example, the most common example would be a database gateway class, such that anything in the business layer that needs to touch the database must go through the gateway.

This concept is very useful in SharePoint as well. I might even say it's a requirement.

SharePoint allows you a lot of power by providing you an object model to work against. You can use this model to query it, to add/remove items from lists/document libraries, and to do many other things. It is therefore imperative to have a clean, logical way to interact with SharePoint's different pieces, one that is able to better reflect how your business layer may need to access it.

Gateways also improve testability. The reason the project I'm currently working on is fairly flexible and solid is that we use a lot of unit tests to verify our assumptions and design. Just the other day, someone made a breaking change to the code, which broke all of the unit tests. We were only able to easily fix these changes because of the use of a gateway to SharePoint. . .it allows us to have a non-SP test harness so that testing goes much faster, and still approximates very well the conditions that are necessary for the go-live situation.

In conclusion, I would argue that gateways should be a foundational pattern that you should learn before starting any large, data-driven project. There are many resources on the web, including a nice series of DotNetRocks (maybe it's TV? I forget exactly) where JP Boodhoo goes deeply into a database gateway class. It's a very good show.
Extension methods, SharePoint, and WordprocessingML

Lately, I've been toying around a lot with SharePoint and WordprocessingML. I have come up with a handful of ultimately simple, and extremely powerful extension methods.

For SharePoint, I have an extension method called TryGetSubFolder (Thanks Trevor via Nadeem for the tip about naming it Try instead of just GetSubFolder, when it can possibly return null), and another extension method called CreateSubFolder. The TryGetSubFolder is the smart one, though. It works on SPFolders, and takes in a lambda expression, the first type of which is SPFolder, the second is a bool. This means that you can do something like this:

SPFolder subFolderNamedChess = spFolder.TryGetSubFolder(x => x.Name == "Chess");

Or:

SPFolder subFolderWith10ContainedFiles = spFolder.TryGetSubFolder(x => x.Files.Count == 10);

 

I don't know why you'd want to do the latter, but there's other things you can do, such as use a lambda to say that you want the first folder that contains a file with a modified date of yesterday (for example).

The CreateSubFolder function does exactly what you would expect - creates a subfolder with the supplied name.

 

The Office Open XML SDK 2.0 CTP has been released, and I'm really liking it so far. It provides a lot of power, and while it has a fairly steep learning curve, it can be made simpler with a few extension methods that I've come up with. Namely, GetOrCreateElementBefore, and GetOrCreateElementAfter.

GetOrCreateElementBefore is a generic function which will add a child element of any type that derives from OpenXmlElement and defines the new operator. It will automatically add it as the first child of the element upon which it is called. This is useful, because some things seem to depend on order, and if an element needs to go first, then it needs to go first.

On the other hand, GetOrCreateElementAfter does the same thing, except it adds the new element as the final child of the element upon which it is called. This is the one I use most often, because order doesn't usually matter, I think.

In programming with the SDK, I've found it utterly necessary to cut down on its verbosity. I wrote my own fluent interface around it so that it's much, much easier to use. Now, instead of adding a bunch of elements in ctors, then using initializers for anything I can't add in a ctor, I can just chain together a few calls, and it'll add everything where it needs to go for me. (For the record, I feel like the fluent interface will not have to change much when the full v2 of the SDK comes out.)

The entire reason for this post is actually because I came up with a way to open up a lot more power with the fluent interface that does not make me have to add a TON of methods to the interface. That method is the GetOrCreateElementAfter, which is very similar to the above, except that it takes in a lambda expression. It would be used, for example, like this:

ParagraphProperties pProps = paragraph.GetOrCreateElementAfter<ParagraphProperties>(
          x =>
          {
              x.FontSize = 32;
              x.FontSizeComplexScript = 32;
              x.Font = "Times New Roman";
          }
);

That's not quite how it works, but only because there's some in-between stuff that I'm not showing where the values for the FontSize and such have to be constructed in a certain way. In any case, that's the gist of it, and it works really well. So, the above is able to utilize a simple lambda expression to open up a lot more power to the fluent interface.

I hope this in some way can help people out! And I certainly hope it makes you think about utilizing lambdas more, which I consider to be some of the most beautiful constructs in all of programmingdom.

Pax,

K

On Simplicity

Lately, I've been thinking a lot about simplicity in architectural decisions. Sometimes, as software designers, we may accidentally do something in a way that is incredibly complicated because we think it's more efficient, or (more often, I think) because we think we need to do it in the complicated way because that's the right way to do it. This is almost always a mistake.

For example, consider prime number generation. It's not really that difficult to do - there are many, many algorithms that do it. We could write a simple Sieve of Eratosthenes class to generate prime numbers between 1 and any integer greater than 1; it's very, very easy to do. However, it's really not that efficient. There are more efficient ways, such as the Sieve of Atkin - it does some work up front, then marks off squares of primes. But it's more complicated.

The point is that unless there's some severe constraint(s) on your system, I don't see any reason to write a program that uses the Sieve of Atkin. In terms of efficiency, simple code is often much easier to make faster/more efficient than code which is complex. In the previous example, it is quite trivial to write a cache which stores the primes generated by the SoE. It's also simple to have that cache be updated upon new numbers being added to the list. Now that you have a huge cache of numbers, it's a simple look-up call and no real work needs to be done. So why bother with the more complex algorithm?

At my first programming position at the artificial intelligence company Quantum Simulations, Inc., I learned a lot about keeping code as simple as possible. With complicated code, it is often much more difficult to go back and make it more efficient, and usually it is much harder to fix bugs in it. With simple code, it's almost always easy to go back and make it more efficient if necessary, and by definition it is easier to fix bugs with simple code.

In terms of efficiency, my former mentor, Dr. Benny Johnson of the above company, and I discussed two main ways to improve efficiency. You can improve efficiency by improving the algorithm being used. If you're doing this, then you better have some good unit tests to verify your algorithm - this way, you automatically catch any bugs that arise from changing the heart of your code. You can also improve efficiency through cutting down the number of times that the inefficient code is called.

Putting this in terms of the example from before, you can decrease the number of calls for prime generation by introducing the caching mechanism, or you can change to the Sieve of Atkin to increase efficiency. It's important to see, however, that just introducing the new algorithm will not really get you much of a benefit because you are still having to do a somewhat heavyweight solution over and over and over. That's one reason why, in my opinion, the second type of efficiency improvement is usually the better form. And generally, it's easier to find places to use caching (and other ways of reducing the number of calls to inefficient or slow code) with simple code than it is with complicated code - with any chunk of code, you may not find that the main chunk of data is cache-able, so with complicated code, you're trying to find little bits of it that can be cached in order to increase its performance. This can introduce a lot of bugs, but aside from that, it's easier to find those places in simple code, and often those places are much bigger in simple code, i.e. you gain a lot more from introducing caching into simple code than you do into complicated code.

That's all for now on simplicity. I hope that this helps you to think about how you write code in the future. Remember, simpler is almost always better. If you have any questions, feel free to email me.

Pax,

K

1 - 10 Next

 ‭(Hidden)‬ Admin Links