Although I am sure not many graphics students read this blog I figured I would announce it anyways. I will be giving a talk to the digital media class from 4:00-6:00pm. Its an open format event so I am sure the topics will be quite varied.
Archive for January, 2009
Tonight I will be joining 4 other local presenters to talk on the SOLID principles. I will be talking on the Liskov Substitution Principle.
It’s at the usual time/place (6:00pm downstairs in the Milner Library).
Hope to see you there!
Well it has been a long time since I got to work with SQL Reporting services but for the most part I really like it.
One problem we had was that we have about 20 reports all with the companies logo on it. We could imbed it in each report but that would result in a lot of duplicated logos.
So the solution we came up with was to use a relative path to a logo contained in the report assembly… easier said than done. Long story short we finally got it to work with the following code:
=”file://” & System.IO.Path.Combine(System.AppDomain.CurrentDomain.BaseDirectory, “..\..\Images\Logo.png”)
A funny thing is that reports run in a sandboxed domain for security reasons. In that sandboxed domain you have a very limited subset of functions you can call. In order for the above code to work we needed to change the domain that the report runs in the current appdomain:
Also the report viewer will not load external images by default so you will need to do the following:
reportViewer.LocalReport.EnableExternalImages = True
And finally we were able to load external images with out having to hardcode in the paths!
For those of you who have not been exposed to the Single Responsibility Principle it states that an object should have a single responsibility and therefore a single reason to change. This results in a codebase having many small classes that do one task.
Today I got asked why SRP is important and came up with a few good reasons off the top of my head:
Readability: The class is easier to read as it performs one task. Anyone should be able to spend under a minute and fully comprehend what the class does.
Testability: There is only one things to test so you write simple small tests that cover the few scenarios the object will experience
Reusability: The class is easier to reuse as it is not locked into one scenario. It can be used in multiple ways as it has set input/output expectations.
Easier To Code: It is easier and faster to code in small chunks than it is in large segments. When coding with SRP it is easy to break off a small chunk of functionality, write it, test it, then tackle another small chunk.
Bugs: By having code broken into many small classes bugs become easier to track down. If you have a 2000 line function and an exception occurs you will know there is a problem in that method. If the code is properly broken out into small 5-20 line methods you can track it down to that small function and usually spot the error in seconds.
Now many developers hate SRP as they end up having hundreds to thousands of classes in their projects. To me this is the only mild detractor of SRP but it is really not that hard to break classes into logical folders/namespaces to make it manageable. And honestly I find this makes things even easier to work with. If I want to get the data for student attendance by day report I may just type:
var reportDataRetriever = new Reporting.Students.Attendance.ByYear.Retriever();
var data = reportDataRetriever.GetDataFor(DateTime.Now.Year);
I find that this is quicker to navigate as I know first off that I want a report and that is in the “Reporting” namespace. Then Intellisence prompts me with all the possible things I can report off of so I pick “Students”. Then what I want for the student and that is “Attendance”. And on and on we go of narrowing things down. This allows me to find what I am looking for without having to remember the name of the class I would want to call.
I have seen way to many classes like this:
Public Class Reports
Public Function GetAllStudentsAttendanceByYear(int year)
Public Function FindTeachersWhoTaught(Course course)
…. 20 other report methods
Public Function StudentAttendanceFor(DateTime startDate, DateTime endDate)
Public Function GetTeachersWhoTaught(int courseId)
… 30 other report methods
To use this class becomes completely unwieldy. Naming convents first off are not consistent which is quite common so it makes it hard to use in intellisense if you have to try “Get______” or “Find_____” or “Student______”. If this was done with SRP then you would still have an inconsistent naming conventions but it would not be a problem as your code would still be easily navigable.
You will also notice that the Reports class example has two methods that return teachers who taught a course. This happens more than one might think in that a developer thought the method did not exist as they did not take the time to look through a massive class to find it did already so they created their own. If you were using SRP you would see in seconds that in the Reports\Teachers\ folder a class called something like a file named WhoTaughtCourse.cs or something similarly named that easily communicates that this work is already done.
A good debate in the development community is whether or not to specialize in something and tout yourself as an expert in just that. If you do specialize you probably will be able to find some good money as people pay well for an expert. On the other hand work is harder to find as you are in a niche and need to find people looking for an expert. Also when your specialization is not popular any longer you need to re-specialize in a new area.
One of the popular sayings in the development circuit is “Specialization is for Insects” taken from Heinlein’s Time Enough For Love. Most of us feel that specialization is the sure way to be good at something and terrible at everything else. Lets face it, as developers we need to solve many different problems and need a well rounded background to solve those problems effectively. Bringing in an expert may solve one problem but then they are discarded and the rest of the team carries on.
One overlooked item is that our offices need diversification (and not just in the we need more than white males working in our industry kind of diversification). By having and encouraging developers to learn things that others don’t know contributes to the entire knowledge of the team. If we are approaching a client/server design and one developer only knows COM+ but the other has a knowledge of WCF then we can discuss the pros/cons of each technology to make an informed choice.
I feel that is important to not have a homogeneous team in some areas. To debate something shows the strengths and weaknesses of decisions and yields a better outcome in most cases. Encourage and hire people that don’t 100% match what you do and bring their diversity into yours. It can help you open up doors to new clients or solve problems with current ones.