If you are using Office365 and hosting a Blog in addition to your “Public Website” it’s a good idea to make yourself aware of the default Fonts and Styles and how they differ from the default Fonts and Styles in Microsoft Word if you are using MS Word to author your blog content.
Recently while discussing templates used to publish FaceBook Posts, Blog Posts, Articles, Courses and Labs the issue of the difference in appearance of certain Fonts and Styles as they are published to a SharePoint Blog from MS Word. There is a fix for this if you are willing to dig a little deeper but for the purpose of this post I will simply illustrate the key differences and a basic work around that will make your posts look as you intended when they are published to SharePoint.
When we start in Microsoft Word with the Font Styles in Figure 1 we end up with published content on our SharePoint Blog that looks like Figure 2.
Figure 1. Font Styles as they appear in Microsoft Word before publishing to SharePoint Blog.
First the SharePoint Blog Post Title uses the same style as a Heading 2 in the Styles list in MS Word so using Heading 2 anywhere in your blog post is probably not a good idea. For topic titles I recommend Heading 3, Normal for body text and Intense Emphasis for notes and callouts with the keywords / phrases in bold.
Figure 2. Font Styles, Colors and Sizes as they appear in Microsoft Word before publishing to SharePoint Blog.
After publishing we end up with changed Font Styles, Colors and Sizes most things appearing larger than they did in MS Word, however some appear smaller. So it’s good to know in advance what those changes will look like so that you and your readers are not “unpleasantly” surprised by the format of the new content you have just published to your SharePoint Blog.
The Test-Driven Development (TDD) Processes follows a pattern known as the TDD Rhythm which dictates the order in which elements of the solution should be created / edited.
Before we can successfully implement TDD a few key agile constructs must exist. Most importantly we must have Tasks derived from a User Stories (or requirements) that define the details of required system feature. These defined details would include the Acceptance Criteria for feature described in the User Story. We would then use the task details and acceptance criteria to define our tests.
The TDD Rhythm
1. Write a Failing Test
The first step in the TDD Rhythm is to Write a Failing Test. Using the Task Details, we write a test that exercises the functionality defined by the Users Story and expects that the value that is returned is the same as the value that is expected based on the Acceptance Criteria defined in the Task Details.
2. Run the Failing Test
Run the test to see it fail. This is an interesting step as depending on your application architecture may require some minimal project structure be created and project references made for your Failing Tests to even compile before they can run and fail. For example, if you are storing all of your Business Logic in a Class Library Project called BusinessRules that compiles as a Windows .dll and your Tests are centrally stored in a Test Project then your Class Library Project will have to Exist and the Namespace, Class and Method will have to exist before your Test Project will compile and the Tests will run and fail. Fortunately, Visual Studio includes code generation tools that will create the Classes and Methods as long as the Class Library Project Exists and at least one class with a Namespace statement exists. The Failing Test generated by Visual Studio will throw a NotImplementedException which will obviously cause the method to fail.
3. Write just enough code to pass the test
This can be a difficult concept to get your mind around for especially when the common simple TDD example code is used. For example, take a method simply returns a Boolean value to illustrate simple TDD method creation if we start with a test that runs the required Boolean method and expect the method to return a true the code to pass the test would simply be return True;
public void TestGetBool()
Figure A. Test Method to test GetBool Method
public static bool GetBool()
Figure B. Minimal code needed to pass the test
With this example it may seem like a waste of time to write this minimal code to pass the test as it is clear that the test needs a returned value of true in order to pass so where is the value is writing this useless passing test? Without writing the test that tests the “unhappy path” through our method (aka the test that expects a return value of false) it is hard to see the value is a method that simply returns true with no additional implementation logic. An eager developer may want to just skip to writing implementation logic without wasting time on the simplest code step of the TDD Rhythm but follow the pattern young Jedi. As seen in a slightly more complex method that returns a formatted string, understanding how the output should be formatted in order to pass the test can potentially be much more difficult than just returning a Boolean value of true.
public void TestWelcomeBack()
string expected = “Welcome Back Antoine! Your last visit to the site was 02/01/2016.”;
string actual = WebSite.BizRules.WelcomeBack(user);
string message = “We should get “ + expected;
Assert.AreEqual(expected, actual, message);
Figure C. Test Method to test WelcomeBack Method
public static string WelcomeBack(object user)
return “Welcome Back Antoine! Your last visit to the site was 02 / 01 / 2016.”;
Figure D. Minimal code needed to pass the test
In this example the Literal String returned including the user name Antoine and the last visit date would obviously need to be updated for each user and on each daily visit but the formatting and welcome statement may also be important and could possibly come from a configuration file somewhere. The point is that the minimal code required to pass the test in this case acts as documentation for the method including formatting requirements for returned values. On the next refactoring pass we would update the code in the method to include the code necessary to extract the user name from the user object passed to the method and retrieve the date of their last visit from the membership database and return it in the expected format. The String Literal is our formatting template as we create the implementation code we know what the expected result format looks like.
4. Run the Passing Test
At this point our method has just enough code to pass the test but does not necessarily meet the business requirement nor does it allow us to perform the task described by the user story. This will become obvious as more tests are developed to tests the “unhappy path” or as varying return values are expected by other tests. But at this point we understand what must be done for the test to pass and can keep that in mind as we refactor the code to make it meet the business requirement or for optimization purposes.
5. Refactor the Code
Depending on “minimal” code we wrote to pass the test our first refactoring pass may be to add required functionality or if the required functionality already exist we may be refactoring for Maintainability, Scalability or Performance Optimization. In any event as we refactor the code for whatever reason we can do so with the confidence that any changes that we make have tests in place to ensure that we have not made a change that would break existing functionality already passing tests. If you make a change and all of the sudden tests that were passing stop passing you know you have a problem. The tests can also be used for Gated Check-ins that require that any changes a developer makes to code must pass existing tests before it can be checked into Source Control allow bugs to be identified before they make into our build and potentially out to customers.
The Expanded TDD Rhythm
6. Run All Tests
Once we have refactored our code to include desired functionality or optimize for maintenance, scalability or performance we need to run all tests to ensure that our changes did not break the method that we were working on but also for any methods that depend on this method or its results. This is a necessary step to avoid failed check-ins on Source Control or Continuous Integration (CI) Servers where Gated Check-ins are used. With gated check-ins your check-in cannot break the automated build and all tests must pass or your check-in will be rejected and your code not allowed into source control until the issues are resolved.
As changes are required we can continue to repeat this process of writing failing tests, coding, passing tests and refactoring until our code for the features we are adding for our updates is “perfect”
A great demo of the canvas element
Canvas Ajax Demo
Details on the use of the canvas element.
A SQL Injection Attack is one of the many security issues that must be address when designing and developing applications that access a database. The injection vulnerability is potentially present on pages or forms where the user must enter a value to be submitted to the server. If the user input is not properly validated and the database doesn’t protect itself then SQLiA can occur. I have posted a sample application under the Demos link in the Downloads section of the mail portal. To download the SQL Injection Attack Sample Web Site and SQL Script click here: VB.Net Version orC# Version To run this demo code you will need Visual Studio 2008 or higher and SQL Server 2000 or higher installed
SQL Injection Demo:
The SQLInjectionDemo.zip file consists of a T-SQL Script file named CustomerOrdersDB_SQLInjection.sql used to create the database, tables (including sample data) and stored procedures (Stored procedures were created usingCRUD Script) and a Visual Studio 2008 project called Demo.sln. The Visual Studio Solution contains 2 pages: SQLInjection.aspx and SQLInjectionFixed.aspx that as the names imply illustrate a page that is vulnerable to SQL Injection and one that is not (not all possible SQL injection attacks are prevented but most).
To test the search feature that’s vulnerable to SQL Injection:Open the Solution (Demo.sln)Select SQLInjection.aspx in the Solution ExplorerPress Ctrl + F5 or Select Start without Debugging from the Debug menuType Antoine into the search boxPress the Search button
Note: You will notice that the results displayed on the page are filtered to show only Antoine Victor. Try a couple more searches then continueCopy the injection statement from the bottom of the pagePaste into the search boxPress the Search button
Note: You will see a list of all of the tables defined in the current database and all columns defined in those tables. Think credit card table, employee table with Social Security Numbers. Armed with this information a hacker could use the same SQL Injection vulnerability in this page to then request columns and rows from the credit card or employees table.
Fortunately there is a relatively easy fix for this. The fix is a 2 part process, first we validate the user input before sending it to the server and removed any special characters or malicious code, and second we make all calls to the database through stored procedures (created automatically usingCRUD Script or theSSMS Toolkit)
To see the page with the Injection issue resolved in the current browser window navigate to SQLInjectionFixed.aspx and follow the previous steps. This SQL Injection issue is now resolved.
For a list of other common injection attacks to test with this demo see: SQL Injection Cheat Sheet.
I learned a very useful T-SQL script formatting trick today. I often talk about formatting and commenting for the “person from mars” which is usually “you” coming back to look at your code 3 years from now having forgotten everything you ever knew about this project and learned better ways to do everything that was done in this project but now you just need to make a “quick” update. How do you find the one piece of code in the thousands of lines of code (perhaps millions) that make up this solution? Well hopefully you left yourself a few clues AKA comments that call out important lines or sections of code and hopefully the code has been formatted in a way that makes it easy to read and debug. Well developers cannot survive on google searches and hope alone! We need to help our future selves out a little. So let’s take a look at a formatting trick that will make your T-SQL statements easier to read and debug. When creating stored procedures, views and user defined functions you may need to comment out one or more lines for debugging or testing reasons, however when all of your code is on a single line it makes it very difficult to comment out a single column reference or where clause. So while debugging stored procedures I used to spend a lot of time (before I learned this new trick) using a keyboard shortcut. The keyboard short I had been using was “Ctrl + Right Arrow” this keyboard short cut skips to the beginning of the next word (commas count as words so it will stop at every comma as well) so in a statement such as: “Select FirstName, LastName, Phone, EmailAddress from Person.Person” the keyboard shortcut will move us from the beginning of the word Select to the beginning of the word FirstName the next time we press the arrow key we will move from the begging of FirstName to just before the comma (after FirstName). Using this short cut the key patter would be Ctrl + Right Arrow 2x (press the right arrow twice while holding down the Ctrl key) then Press Enter (to move “, FirstName” to the next line) then Ctrl + Right Arrow 2x, Enter (to move “, LastName” to the next line). Repeat for each column in the table. This works and I’ve been using it for years but there is a better way! The New Way… Using Search and Replace we can replace all commas with a carriage return and a comma. Ctrl + H opens the search and replace window. In the find what box type a comma. In the Replace with box type \n, then in Find Options select the “Use:” checkbox then choose Regular Expressions from the dropdown. This will replace all commas with a carriage return and a comma. Converts this: Select FirstName, LastName, Phone, EmailAddress from Person.Person To this: SelectFirstName, LastName, Phone, EmailAddressfrom Person.Person
If you are reading this post you have of course heard the term DataBase… Depending who you are and what you do for a living that term may or may not mean anything to you. If you are a DBA (DataBase Administrator) look away! This post is not for you. lol This post is intended for those who have no idea what a database is or what Microsoft SQL Server is or why they should care.
OK so now that we’ve got that out of the way on with the definition.
What is SQL Server?
SQL Server is Microsoft’s RDBMS (Relational DataBase Management System). Like its competitor Oracle, Microsoft’s SQL Server is the database applications that a website or other application might use to store its list of Customers, Orders, Products and Employees. If you have booked a flight reservation on line (or by phone) or you have a Costco or Netflix member ship then you have no doubt been exposed to a database and perhaps even had your purchasing habits stored in the database and used to market products to you that the vendor knows you want. Put simply Microsoft SQL Server is a DataBase product used to store the data collected and used by a variety of computer software applications. It is a giant electronic file cabinet for your computer based data.
These days most organizations (Microsoft shops) are running Microsoft SQL Server 2005, Microsoft SQL Server 2008 or Microsoft SQL Server 2008R2. You can install Microsoft SQL Server 2008R2 software on a server in your office or you can run SQL Server in the Cloud! For more information about Microsoft SQL Server in the cloud see the following article: Introduction to the Cloud and Windows Azure