William Cameron | Beyond the Keyboard

In today's threatscape, antivirus software provides little piece of mind. In fact, antimalware scanners on the whole are horrifically inaccurate, especially with exploits less than 24 hours old. After all, malicious hackers and malware can change their tactics at will . Swap a few bytes around, and a previously recognized malware program becomes unrecognizable. Sure sign of system compromise No. 1: Fake antivirus messages In slight decline these days, fake antivirus warning messages are among the surest signs that your system has been compromised. What most people don't realize is that by the time they see the fake antivirus warning, the damage has been done. Clicking No or Cancel to stop the fake virus scan is too little, too late. The malicious software has already made use of unpatched software, often the Java Runtime Environment or an Adobe product, to completely exploit your system. Sure sign of system compromise No. 2: Unwanted browser toolbars This is probably the seco...

Anybody who does object oriented development quickly learns about type hinting - the process by which you can indicate to one object another object it should expect. Remember this example from the last post? <?php class MyClass() {   public function __construct(MyObject $mobj) {     $this->myObject = $mobj;   } } But type hinting alone is not sufficient to loosely couple our objects. In fact, even though we are injecting our dependency in the initial example, we're type hinting on a concrete object, meaning that we are tied to that specific object for all future iterations. Sure, we can mock it for testing (which is an advantage), but we can't easily subclass it and use it elsewhere. Fixing the Type Hint Tight Couple It's easy to fix this particular tight coupling problem. To do so, we can draw back on our knowledge of SOLID principles, namely the Dependency Inversion Principle, which states: Objects should rely upon abstractions, not...

What Is Tight Coupling? It would help to define exactly what the problem is, in order to solve it. Tight coupling, in object oriented application, is an abnormal dependency between two unrelated objects. This usually manifests itself in a few different ways; today we're going to talk about the first type: the object creation tight couple. The Object Creation Tight Couple Have you ever seen or written code like this? <?php class MyClass(){   public function __construct(){     $this->myObject = new MyObject();   } } We've all probably observed this. Even if it's in another method besides the constructor, we've all seen code that creates other objects. The culprit here is the new keyword. This keyword creates an object, but the creation of an object tightly couples one object to another. It's impossible to easily swap one object for another. Solving The Object Creation Tight Couple There are a few easy ways to solve this particular type of problem. The first ...

When it comes to ecommerce analytics, business owners and marketing managers typically focus on metrics like conversion rates, number of transactions, and average order value. These are valuable, and should be monitored. After all, measuring such outcomes is what directly impacts revenue and the bottom line. Thanks to Google Analytics as well as Mixpanel, Flurry, Site Catalyst, and other analytics platforms, these ecommerce metrics are readily available to site owners. While focusing on the outcomes is key, close attention to tracking user behavior and interaction with the site or mobile app will also yield significant incremental improvements. Here are five interactions you don’t see a lot of people measuring, when they really should be. Product Categories You can easily report on top products, what’s selling, and what’s not selling on your website. However, go beyond that and consider rolling up your reports to the product category level. Some categories can be driving more ...

In computer programming, SOLID (Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion) is a mnemonic acronym introduced by Michael Feathers for the "first five principles" identified by Robert C. Martin in the early 2000s that stands for five basic principles of object-oriented programming and design. The principles when applied together intend to make it more likely that a programmer will create a system that is easy to maintain and extend over time. The principles of SOLID are guidelines that can be applied while working on software to remove code smells by causing the programmer to refactor the software's source code until it is both legible and extensible. It is typically used with test-driven development, and is part of an overall strategy of agile and adaptive programming. S - SRP - Single Responsibility Principle - A Class should have only a single responsibility. O - OCP - Open/Close Principle - Entities shoul...

For the 2013 holiday shopping season, consumers will increasingly rely on marketplaces and comparison-shopping channels.  Amazon, Newegg, Ebay, Google Shopping — all have huge numbers of motivated shoppers.  Ecommerce merchants large and small can sell on these channels. But not all of them will do it profitably.   1. Products. Identifying winning products is the first step. Research last year's best sellers, evaluate new products, and consider niche offerings and up-sells.  2. Sourcing and inventory management.  Ensuring product availability is crucial. The necessity of placing orders early and check for add-on items. 3. Product content and feeds. Compelling images, descriptions, and videos are all important for selling products on marketplaces and comparison-shopping channels. Optimize your product content and data feeds. 4. Pricing. Understanding your margins is vital for profitable multichannel selling. Understand dynamic pricing and stra...

Lots of developers understand that object oriented code offers advantages over procedural programming. And so, they begin working on creating objects in their own projects, and eventually feel pretty good about what they've done. After all, if they're using objects, their code must be object oriented, right? Well, not exactly. They quickly find out just how limited their code is when they try to implement the concepts of object oriented programming, like reuse and extensibility. And they quickly find that their code is really procedural code wrapped up in classes, not the grand object oriented application they thought it was. But how can you know ahead of time what kind of code you have? Is there a set of tools you can use to determine if your code is truly object oriented, or is it just procedural code wrapped in classes? Let's take a look at the hallmarks of truly object oriented code and find out. Object oriented code splits responsibilities between classes. The big...