Wednesday, June 24, 2015

Disable Skype Auto Start

Skype starts automatically and it is pretty trivial how to disable it but you have to know how and that's the key which is why I'm writing this. It doesn't show up in the Registry under Software | Windows | CurrentVersion | RunOnce.

So here is how to disable it:

Launch Skype and login. This is the key step because if you don't login the options are different. Go to the Tools menu and choose Options, under General Settings you'll see the checkbox for start Skype when I start Windows. Uncheck that and you're good!

If you don't have a Skype account, then I think you're out of luck because I've used ProcessMonitor to monitor the registry access and haven't been able to find a manual way to disable this.

Monday, June 22, 2015

Enums in Bash

I find that I use a lot of bash scripts. Using cygwin on Windows, Mac and Linux they are cross platform (for the most part). One feature lacking in bash is enums, but you can simulate them. I ran across this StackOverflow post and there is a nice comment about enums in bash, but it isn't complete.

#!/bin/bash

STATES=(INITIAL DEFAULT_CS_SETUP CREATED_CS CHECKED_OUT_DIR MKELEMENT_FILE CREATED_BRANCH CHECKED_IN_DIR COMPLETE)
tam=${#STATES[@]}
for ((i=0; i < $tam; i++)); do
    name=${STATES[i]}
    declare -r ${name}=$i
done

echo get the INITIAL state
echo ${STATES[$INITIAL]}

echo get the next state from CREATED_CS
echo ${STATES[$CREATED_CS+1]}

echo list elements from CREATED_CS to the end
for ((i=$CREATED_CS; i < $tam; i++)); do
    echo ${STATES[$i]}
done

echo list elements from CREATED_CS to CREATED_BRANCH
for ((i=$CREATED_CS; i <= $CREATED_BRANCH; i++)); do
    echo ${STATES[$i]}
done

Often times I want to create an empty enum and add items to it. So here is my example of creating an enum type, OPTION_STATES, defining the enum values and adding an item to it and checking for it later.

#!/bin/bash

# Define enum type.
OPTION_STATES=(OPTION_ONE OPTION_TWO OPTION_THREE)

count=${#OPTION_STATES[@]}
for ((i=0; $i < $count; i++)); do
    name=${OPTION_STATES[$i]}
    declare -r ${name}=$i
    
    if [[ $DEBUG == true ]]; then
      echo $name $i
    fi
done

# Create instance of enum type, yes this is a hash table.
OPTIONS=()

# Put an element into the instance.
OPTIONS[$OPTION_ONE]=$OPTION_ONE

# Check if that element is in the instance.
if [[ ${OPTIONS[$OPTION_ONE]} == $OPTION_ONE ]]; then
  echo "woo hoo"
fi

Tuesday, June 16, 2015

Desk Ergonomics - Every Diagram on the internet is wrong!

I ran across the following image recently from the article here.


The image is courtesy of Ergotron but I never found it on their website or I would have provided a link other than that one. On a side note, I have tried to use an Ergotron, but it didn't work for me. I'm too tall for one, two it didn't stay clamped to the desk, three the springs were too weak for my monitor, four it bounced when I typed. For someone else it might work out though. I know other people that like them. I think they are shorter and use a smaller monitor.

Anyway, back to my point. I honestly can't stand diagrams like this that have been floating around as long as I've used a computer for the correct ergonomic positioning. There are so many things wrong with this from a movement and ergonomic perspective it isn't even funny. Anyway, I'm going to start writing about this in future articles, but I wanted to point out a couple major issues with this diagram for "ergonomic perfection".

1. The legs are parallel to the floor. Not good. You want your thighs slightly sloped toward the knee. Same goes for the elbow. However sloped forearms makes using a mouse difficult, but I have a solution for this that I will post about in the future. The correct angle for legs and arms is 120 degrees. This isn't always achievable but that is as close to neutral as one can get without standing with their arms at their side and palms facing their legs.

2. The height of the monitor is incorrect. Monitor placement is an extremely complicated subject. It depends on your size and the size of the monitor, and most importantly, where on the monitor you look the most. Like I said, it's complicated. Your eye muscles are very strong in holding your eye up so you can look down, but are much weaker when looking up, so you certainly don't want to be looking up too much. I will write a future post about monitor placement because this is so important.

Monday, June 15, 2015

Rasperry Pi - How can I fix broken sudo - sudo: parse error in /etc/sudoers near line 29?

I recently got a Rasperry Pi and I've googled for many little oddities so I figured I'd write them up here on this blog to save anyone else out there some time.

I decided to create a new account it administrative privileges. So I create a new account for myself and enable sudo for it.

sudo adduser chris

Then add a line to the /etc/sudoers like so.

sudo visudo

This will open the /etc/sudoers file in nano, add a line just like the one already there for the pi user.

chris ALL=(ALL) NOPASSWD: ALL

However, I spelled PASSWD correctly. And consequently get:

sudo: parse error in /etc/sudoers near line 29
sudo: no valid sudoers sources found, quitting
sudo: unable to initialize policy plugin

Can't shutdown, can't edit /etc/sudoers. So I thought I was stuck. Looking online if you have Linux you can put the SD card in your card reader, and mount the file that is rasparian image and edit to your hearts content. On Mac you can sorta do it with Fuse-ext2. Here is the best set of directions for that http://pi.gbaman.info/?p=328. But, I decided to try something I hadn't seen before:

logout

Then I logged in with "root"! Now I could edit /etc/sudoers all I wanted.

Friday, June 12, 2015

Windows 10

I just installed the Windows 10 preview in a VM on my Mac. So far so good! I think this is going to be a pretty good release of Windows.


Thursday, June 11, 2015

iOS Privacy Settings

Here are a couple privacy settings that I like to make changes to and I'm documenting here so I can point friends and family to this post.

1. Settings, Privacy, scroll down to Advertising, turn "Limit Ad Tracking"

2. Settings, Privacy, Location Services, scroll down to System Services, Frequent Locations, turn it off.

Thursday, May 28, 2015

Unit Testing JavaScript

Recently I was working on some JavaScript that really needed unit tests. I was making a substantial change that could not introduce any regression bugs and is very difficult to black box test. After all, this JavaScript was live! After digging into it a bit, reading the JavaScript spec since I'm more familiar with other languages like C/C++, Java and C#, I came to the conclusion it was going to be difficult so set off on a journey to see how others did it so I could save myself some time reinventing the wheel. My Google search of "unit testing private methods javascript" resulted in coming across the blog post How to Unit Test Private Functions in JavaScript.

The solution provided by Philip Walton was pretty good, but has a couple caveats. First let me explain what his solution is so you don't have to go read his entire post before continuing. He concludes that there are two camps of testing private JavaScript methods:

1. Don't
2. Everything is public

Obviously that isn't so good so he came up with a new option:

3. Export the private methods so they are public but do it in such a way that a code stripper removes them before going live.

The code stripper option isn't much of a stretch because most JavaScript goes through a compression process anyway removing white space and comments. I like his option but for me it wasn't an option to be able to modify the code stripper. We use YUI Compressor and aren't going to modify it. We could add a preprocessor but that isn't an option at this point. Plus there is potential for bugs because the code that is live isn't the same as the code you are testing. Our stripper has been around for a long time so we have confidence in it. So I came up with a new option:

4. If a global variable has been introduced and the .js file is loaded from a specific URL then initialize the global variable with a closure class containing only the private methods you want to test. For example if the URL is contains "http://localhost" or "file://", then initialize the closure. Any URL could be added here, including an internal test URL. However I can see how publishing a private URL is undesirable no matter how difficult it is to read.

For example:

var myclass = function() {
    // Private
    function someInternalMethod(arguments) {
    }

    function anotherInternalMethod(arguments) {
    }

    function initialize() {
      if ((typeof __myclassTestHook__ !== 'undefined') &&
           (__myclassTestHook__ == null) &&
           ((window.location.href.indexOf('http://localhost') == 0) ||
           (window.location.href.indexOf('file://') == 0))
           ) {
           __myclassTestHook__ = {
            someInternalMethod: someInternalMethod,
            anotherInternalMethod: someInternalMethod,
         };
        }
    }

    // Public
    function publicMethod(arguments) {
    }

    function anotherPublicMethod(arguments) {
    }

    initialize();

    return {
        publicMethod: somePublicMethod,
        anotherPublicMethod, anotherPublicMethod
    };
}();

Now:

<script>
var __myclassTestHook__ = null;
</script>

<script type="text/javascript" src="testexample.js"></script>


then use it like this:

<script>

    var stuff = __myclassTestHook__.someInternalMethod();
</script>


Is this perfect? No, but it comes pretty close in my opinion. What are your thoughts? The biggest concern is introducing security vulnerabilities.

Monday, May 4, 2015

Mountain Unicycling

Mountain Unicycling is the best sport I have every done. By far the most energy expended for the amount of time spent ratio. Check out this video if you are at all interested and want a challenge!


Thursday, April 30, 2015

Homeland Security wants less Encryption

The full text of the speech given by the Remarks by Secretary of Homeland Security Jeh Johnson at the RSA Conference 2015 can be found here. I think it is very telling where Homeland Security is from this small except:

"Now, finally, I have an ask: for your indulgence and your understanding on the subject of encryption. 
The Department of Homeland Security has both the cybersecurity mission and a law enforcement/counterterrorism mission for the American people. We have feet in both camps. I therefore believe I have a good perspective on this issue. 
The current course we are on, toward deeper and deeper encryption in response to the demands of the marketplace, is one that presents real challenges for those in law enforcement and national security.
Let me be clear: I understand the importance of what encryption brings to privacy. But, imagine the problems if, well after the advent of the telephone, the warrant authority of the government to investigate crime had extended only to the U.S. mail.
Our inability to access encrypted information poses public safety challenges. 
In fact, encryption is making it harder for your government to find criminal activity, and potential terrorist activity. 
We in government know that a solution to this dilemma must take full account of the privacy rights and expectations of the American public, the state of the technology, and the cybersecurity of American businesses."
First of all, uh, no. Second, are you kidding? The government has mountains of information in the form of metadata that they need absolutly no warrant for. They want back doors which make the encryption pointless. Maybe it's time some smart Silicon Valley engineers work for them rather than just VPs and Execs getting cushy jobs. Just sayin'. If other industries can do it like Monsonto with the FDA why not us?

Tuesday, April 28, 2015

Properties in C++ Part II



Last week I posed about making properties in C++. That code sample had some issues that I fine tuned with the code sample in this post. Here is the new class(s).

template <typename ObjectType, typename ValueType, ValueType (ObjectType::*getter)(void), void (ObjectType::*setter)(ValueType)>
class Property {
private:
    ObjectType* FObject;
    
public:
    Property() {
        FObject = NULL;
    }
    
    void SetInstance(ObjectType* Value) {
        FObject = Value;
    }
    
    // To set the value using the set method.
    ValueType operator =(const ValueType& Value) {
        assert(FObject != NULL);
        (FObject->*setter)(Value);
        return Value;
    }
    
    // The Property class is treated as the internal type.
    operator ValueType() {
        assert(FObject != NULL);
        return (FObject->*getter)();
    }
};

template <typename ObjectType, typename ValueType, ValueType (ObjectType::*getter)(void)>
class ReadProperty {
private:
    ObjectType* FObject;
    
public:
    ReadProperty() {
        FObject = NULL;
    }
    
    void SetInstance(ObjectType* Value) {
        FObject = Value;
    }
    
    // The Property class is treated as the internal type.
    operator ValueType() {
        assert(FObject != NULL);
        return (FObject->*getter)();
    }
};

template <typename ObjectType, typename ValueType, void (ObjectType::*setter)(ValueType)>
class WriteProperty {
private:
    ObjectType* FObject;
    
public:
    WriteProperty() {
        FObject = NULL;
    }
    
    void SetInstance(ObjectType* Value) {
        FObject = Value;
    }
    
    // To set the value using the set method.
    ValueType operator =(const ValueType& Value) {
        assert(FObject != NULL);
        (FObject->*setter)(Value);
        return Value;
    }
};

template <typename ObjectType, typename ValueType, ValueType (ObjectType::getter)(void), void (ObjectType::setter)(ValueType)>
class StaticProperty {
private:
    
public:
    StaticProperty() {
    }
    
    // To set the value using the set method.
    ValueType operator =(const ValueType& Value) {
        (*setter)(Value);
        return Value;
    }
    
    // The Property class is treated as the internal type which is the getter.
    operator ValueType() {
        return (*getter)();
    }
};

template <typename ObjectType, typename ValueType, ValueType (ObjectType::getter)(void)>
class StaticReadProperty {
private:
    
public:
    StaticReadProperty() {
    }
    
    // The Property class is treated as the internal type which is the getter.
    operator ValueType() {
        return (*getter)();
    }
};

template <typename ObjectType, typename ValueType, void (ObjectType::setter)(ValueType)>
class StaticWriteProperty {
private:
    
public:
    StaticWriteProperty() {
    }
    
    // To set the value using the set method.
    ValueType operator =(const ValueType& Value) {
        (*setter)(Value);
        return Value;
    }
};

As you can see there are several classes. I moved the read/write/readwrite enum from being a field of the property class to being a class. I also added static versions. Oh, why would one want a static property? Well, here are a couple examples of using these:

class Environment {
public:
    Environment() {
        PropertyTest.SetInstance(this);
    }
    
// Property
private:
    std::string FPropertyTest;
    
public:
    void SetPropertyTest(std::string Value) { FPropertyTest = Value; }
    std::string GetPropertyTest() { return FPropertyTest; }
    
    Property<Environmentstd::string, &Environment::GetPropertyTest, &Environment::SetPropertyTest> PropertyTest;

// Static Property
private:
    static std::string FTest;

public:
    static void SetTest(std::string Value) { FTest = Value; }
    static std::string GetTest() { return FTest; }
    
    static StaticProperty<Environmentstd::string, &Environment::GetTest, &Environment::SetTest> Test;
};

StaticProperty<Environmentstd::string, &Environment::GetTest, &Environment::SetTest> Environment::Test;
std::string Environment::FTest = "foo";


There are a few limitations still. For example, the dot (.) operator cannot be overridden. So doing:

printf("%s\n", Environment::Test.data());

isn't going to work. The arrow (->) operator can be overridden, so this behavior could be supported that way if one was so inclined. Seems a little odd. I could go either way.

Monday, April 20, 2015

Properties in C++

A long time ago when I was working on Borland C++ and Delphi was just a baby, we added properties as a language extension to C++. Nobody at the C++ committee liked the notion (not sure why, but Java didn't like it either), but I came up with a way of doing properties in C++ using templates. Here is the property class:

enum PropertyType {READ_ONLY, WRITE_ONLY, READ_WRITE};

template <typename Container, typename ValueType, PropertyType Type>
class Property {
private:
    Container* FObject;
    void (Container::*FSetter)(ValueType value);
    ValueType (Container::*FGetter)();
    
public:
    Property() {
        FObject = NULL;
        FSetter = NULL;
        FGetter = NULL;
    }
    
    void InitializeSetterGetter(Container* Value,
                                void (Container::*Setter)(ValueType Value),
                                ValueType (Container::*Getter)()) {
        assert(Type == READ_WRITE);
        FObject = Value;
        FSetter = Setter;
        FGetter = Getter;
    }

    void InitializeSetter(Container* Value,
                          void (Container::*Setter)(ValueType Value)) {
        assert(Type == WRITE_ONLY);
        FObject = Value;
        FSetter = Setter;
    }

    void InitializeGetter(Container* Value,
                          ValueType (Container::*Getter)()) {
        assert(Type == READ_ONLY);
        FObject = Value;
        FGetter = Getter;
    }
    
    // To set the value using the set method.
    ValueType operator =(const ValueType& Value) {
        assert(FObject != NULL);
        assert(FSetter != NULL);
        (FObject->*FSetter)(Value);
        return Value;
    }
    
    // The Property class is treated as the internal type.
    operator ValueType() {
        assert(FObject != NULL);
        assert(FGetter != NULL);
        return (FObject->*FGetter)();
    }

};

Now, to use this, call one of the Initializer* functions from within your classes constructor, provide getter and setter methods and instantiate the property as follows:

class TestProperty {
protected:
    std::string FMyProperty;
    
public:
    TestProperty() {
        MyProperty.InitializeGetter(this,
                                    &TestProperty::SetMyProperty
                                    &TestProperty::GetMyProperty);
    }

    std::string GetMyProperty() {
        return FMyProperty;
    }

    void SetMyProperty(std::string Value) {
        FMyProperty = Value
    }
    
    Property<Process, std::string, READ_WRITEMyProperty;
};

It's a bit more work than if you were to use a language that supports properties such as Delphi or C#, but it can be a very handy syntactic sugar.

Monday, March 30, 2015

Workout - Functional Patterns

The title says it all: "This is not CROSSFIT this is FUNCTIONAL PATTERNS". This is an extremely ergonomic and healthy way to workout. CrossFit is not safe. Seriously, it isn't. Most instructors are not knowledgable enough which is why CrossFit is so popular. It takes a few days to get a CrossFit certification. Lots of cling and jerky movements where as "Functional Patterns" is very round, front back side to side. Simply awesome!