Inversion of Control is based on the idea of flow control. When you start programming, you learn to write code in classes and methods that control the flow of the program. Your code calls methods that do something and answer back to your code. In Inversion of Control, your central classes wait for the phone call that tells them things they need to know to perform their own activities.
Wujec talks about 3 parts of the brain and how we get meaning out of imagery, motion, etc. He talked about how the brain visually interrogates what it sees, develops a series of questions and then develops a mental model.
This is probably the most thought provoking video I've seen in quite a while. Shirky talks about how media is increasingly a result of amatuer or citizen reporters. It's no longer controlled by professionals & government. It talks about China's Great Firewall and how they now have to shut down services to control the amatuer producers.
Since "Art of Unit Testing" is out and everyone is talking about it, I've decided to catch up on some reading about Unit Testing in general before I buy the book. Tech training & rewriting MS labs tends to suck my brain dry. And MS courses are not known for going over things like Unit Testing. After a year of rewriting labs for the LOD, my brain is mush except for debugging MOC labs. Nows as good a time as ever to compile of list of must reads on Unit Testing. So without further ado, here's the list so far:
I know there are more. I've seen them, even read one sometime last fall that was quite good.
Capturing contact information is one of the most important activities companies that sell high end services and products can do. Selling high-end expensive services or products are not items people click a few buttons to purchase. They require conversation and persuasion from the service provider/seller. People don't click a button to purchase a house or an advertising campaign from an advertising company.
On the internet, most search engine optimization experts are familiar with the term "linkbait" which helps get links pointing to a website. Blog content is a good source of linkbait as are useful web applications. This however isn't necessarily capturing that all important contact information.
Get this, this tweet on twitter caught my eye:
Check out the Blogging ROI Toolkit from Compendium Blogware. It's a search marketer's quick guide to business blogging. <url deleted>
I was interested in the whole ROI (return on investment toolkit). I thought WOW a toolkit that might help define return on investment information for me while talking to clients about search marketing. So I went over there and signed up despite the request for information about budgeting and call for a demo checkboxes. Those checkboxes should have been my first clue. It didn't really deliver on the whole ROI Toolkit idea but the idea was good.
Here's what they did right and what they did wrong:
First of all, the title "Blogging ROI Toolkit" was a bit skewed. It did capture my attention. I did want to get a tool that helped determine Return On Investment for blogging. The target "search marketer's quick guide" seemed like it might target a web development company and web marketing company. While I did go ahead and submit my data, the return wasn't what I expected.
Rule 1: Deliver what you promise.
While this may seem easy, it can depend on how you say something. The word "toolkit" implied that there would be a group of tools that delivered a ROI. A simple checklist while useful, doesn't really deliver a "toolkit". A better wording would have been "Business Blogging Success Checklist" . It's just as important to be specific about what you're delivering as it is to deliver it. The last part about "quick guide to blogging" in the second sentence would have been more appropriate because a checklist could be a quick guide.
Rule 2: Target the right market.
In this case, the target market seemed like "search marketers" which based on the fact that these people are selling a marketing service isn't really a good target. A more appropriate target market would be "corporate guide to blogging". This is a little less targeted towards "search marketers". The checkboxes would have somewhat thinned the crowd of actual competitor submissions during the initial qualifying submissions.
So those are the first 2 rules about developing Contact-CaptureBait. I'm sure others will be able to add to this list.
There are times when you may find yourself writing code to move data from a type you defined to another type either predefined or user defined. Of course we are all aware of polymorphism between derived types. This isn't always possible or practical depending on your intentions. It is particularly hard when you're converting between a primiritive type and a user defined type. The answer to this dilemma is to define your own cast.
Here’s just a few notes on preprocessor directives.
They’re never terminated by a semi-colon.
They can never be translated to any commands in code
They affect the compilation process
They can prevent compilation of positions of source code. This is great for having 2 release versions of your application. It’s also great for eliminating debug information source code.
# define identifier
This directive tells the compiler that the identifier or symbol exists. It does not define a valid you for that identifier. These symbols work as a true or false designator.
# undef identifier
This directive tells the compiler that the identifier or symbol should cease the existing. Any test for the identifier will result in a false reading.
In either case nothing will happen if the symbol does or does not exist.
#if Identifier
//some code
#endif
This directive combination tells the compiler to conditionally execute the code block between the directives based on the return of the identifier. If the identifier has been defined using the #define directive, the code will execute. If it has not been defined or has been undefined using the #undef directive the code will not execute.
#elif
This directive acts the same way as and else if statement. It fits in with the #if and the #endif directives.
#if Identifier
//some code
#elif otherIdentifier
//some code
#endif
C# Allows you to use comparison operators like && and = =.
#warning #error
These directives cause warning or error messages when the compiler encounters them. The error directive will display any text to the user as if it were a compile error and then stops compilation whereas the warning directive will continue compiling the application.
#region
#endregion
These directives work in conjunction with each other to organize the layout of your code. They don’t affect compilation.
#line
This directive will alter the file name and line number information to output by compiler warnings and error messages. This is most useful when coding in conjunction with some other assembly that might alter the code you type in before sending the line number to the compiler and the line numbers may not match up correctly.
#pragma
This directive will suppress or restore compiler warnings. It can be implemented on class or method levels.
A lot of times I get asked to take a look at an idea for a web site that a friend or colleague not involved with the IT industry has come upon. Most people have no idea what it takes to build a web site or a piece of software. Many times the idea is not very well thought out. A lot of people get caught up in their ideas and don’t consider the exactly how much work it might take to actually build the web site or software. That’s not their fault because they generally don’t know what it takes.