A thought struck me just today when I was thinking about a guy who pitched me an interesting idea in the education sector. He was young and was almost finishing up college. He had a team of five guys who were all going to work together to put out a working product in a short time (like six weeks). Then I never heard from the guy and later found out that nothing really happened.

We live in a time where startups are a sexy thing. Now I am not sure if it had always been this way or it’s just more ubiquitous now. Either way I see and hear about too many interesting startups that never even make it past the idea stage. I think larger part of the problem is this perception about starting up. Everyone wants to do it because it is cool to be a entrepreneur or a startup guy. Rarely you see a guy who really wants to solve some specific problem and truly care about the end user having that problem solved.

Startups are hard. Really really hard. Really really really really hard. There are too many times and reasons where giving up seems like the right thing to do. There will be people around you, sometimes your team, sometimes your alter-ego telling you that it’s time to pack up. And then it will happen again the next day. And the day after. To be able to persevere through all that every other day is when you even have the probability of succeeding. To have this sort of perseverance you truly need to be passionate and care about your solution and your customer who needs your solution.

So here’s something to think about. Next time you wanna tell someone that you are doing a startup you better be sure for yourself that you actually are doing it! And that is not because you had an idea, not because you started working on something, not because someone said your idea/product was cool or interesting, not because you got selected to a competition or accelerator, and even not because you launched! It has to be because you had some real validation. Real validation is when someone will put money on the table for your work (customer or investor), not because they are your rich cousin but because they don’t give a flying rats ass about you but they have fallen in love with your work!

You actually can’t do this (at the time of this post). But you can work around it.

The Problem

Let me explain what I am talking about. When you use the typescript compiler (tsc or use any extension of it such as the grunt-typescript), when you specify a set of .ts files to be compiled to a specific destination, tsc would compile the given files as expected. However if you have references in the list of .ts files to other .ts files that are not include in the given list of files, the files that were not included also will get compiled along with the given .ts files and placed relatively in the given destination path. There is no actual way to avoid this or restrict this when compiling.

This might sound like something you don’t need but as your project grows you may need to restructure the project or do targeted compiling of only specific files, you can’t simply use a compiler switch to do this. A very good example is placing source and test files in different locations. Take the following structure (an outcome of my previous post). The app/ folder only contains .ts files. The test/ and www/script folders are expected to have the compiled .js

project/
app/
script/
test/
test/
www/
script/

Now if you want to compile your scripts and your tests (from app) to go into two different locations (respectively www/script/ and test/), it’s not as simple as running two tsc commands with the related source and destination paths. Since the test files will reference the files in app/script/ the compiler will recompile the referenced files and place them in test/.

There are two ways to deal with this. For both of them you will need to use a workflow management tool like Grunt to make them work sensibly.

Using Declarations

One way to go is, to avoid referencing .ts files that are not within a compilation target. Instead generate definition files (.d.ts) and reference them. In our example case we have two compilation targets – app/script/ and app/test/. In this case we avoid referencing the .ts files in app/script/ within the test files in app/test/. Instead we generate .d.ts files for all .ts files in app/script/ and then reference them in the test files in app/test/.

This can be done with the compiler switch --declaration when using tsc. For grunt-typescript task you can use declaration: trueoption to do the same. So your Grunt workflow would look like.

When writing your test files in app/test/ make sure to add the references to the source files as a .d.ts (not yet available) instead of .ts.

Compileapp/script/ with the --declaration option which will generate the .d.ts files in the same location as the .ts files.

Compile app/test/ to test/ .

Using similar relative paths

You can use a single compilation command/step which will compile all the files into relative paths. This however alone is not going to solve our problem in the above example. Lets look at how this works.

This time we use a single compile step targeting app/ and everything in there to www/ which will create www/script/ and www/test. This method does not duplicate the .js files, but it puts the test/ in the wrong place. We can fix this by adding two more steps into the workflow. Lets look at how our workflow is going to be when we use this approach.

Compile app/ to www/ which will create both the script and test folders in the www/

Use the grunt copy task to copy the www/test/ back to the root of the project.

Of course you can be done with the first step if your source path and destination path are both relatively same. If you are able to structure you project in such way life will be quite easy for you.

Conclusion

These workarounds don’t solve bigger problems such as the need to compile only the files that are changing. This becomes a nightmare in very large code bases where you have workflow configured to watch and compile only file that are changing.

Hopefully TypeScript team will put in a sensible solution for this in future releases. If you would like to add something to this please post it in the comments.

I wanted to get TypeScript working on an Ionic project that I am starting, but couldn’t find a decent resource that helps you get TypeScript working with Yeoman generated Ionic project. So I thought i’d put down a few steps that will be useful for anyone who might need it.

Environment Requirement

This post is only going to work for you if you are using the following tools/frameworks for the given purposes.

Yeoman for scaffolding and Grunt for workflow/build automation. Honestly if you haven’t heard of these or tried these, you definitely should give it a try before starting your Ionic/Angular project (or for that matter, any JS/HTML project).

TypeScript as your language. There is so much hype around TypeScript and ES6 right about now. Angular 2 supposedly is going to support TypeScript strongly and if you are starting a Angular project with 1.x, you should consider going with TypeScript and structure your code in such way that it can be easily ported to Angular 2 in time to come. (Hopefully I will be writing a series of posts on this).

Create the Ionic Project with Yo

Once you have all this in place you need to use the generator-ionic generator to bootstrap your project. So lets first install the generator using NPM.

npm install -g generator-ionic

Once you have the generator globally installed, you can bootstrap your project folder. Start by creating the project folder, navigating into it and then use the generator to create the project. There will be few steps to let you customize the project.

yo ionic [app-name]

The newly created project structure will have all the files necessary to get started with your Ionic project. You can use the Grunt CLI commands to run, emulate, test and do other things as specified in the generator-ionic page.

Include TypeScript into the Workflow

Now that we have the Ionic project structure, we need to include the TypeScript compilation step into the Grunt workflow. First you are going to need the grunt-typscript Grunt plugin to do this.

npm install grunt-typescript --save-dev

Next we need to make changes to the newly created Gruntfile.js to include and configure the typescript task. First include the plugin by placing the following line in the file. You can put this line somewhere before the grunt.registerTask statements.

grunt.loadNpmTasks('grunt-typescript');

Once thats done we need to include the configuration for the typescript task. This needs to be added into the grunt.initConfig block.

The configuration contains two parts, one for the main code and one for the test code. As you can see the yeoman.xxx (defined in the same grunt.initConfig block) is accessed to get the correct paths for the source and distribution. This configuration will compile all .ts files in the source path (in this case the app folder) and move the resulting .js and .map.js files to the distribution path (in this case the www folder). You can do similar configuration for the test code (currently compiles into the same path). All other available configuration are defined in the grunt-typscript page.

Next we need to add few more lines into the watch configuration (again in grunt.initConfig) to ensure the .ts file changes will run the typescript compiler on those files.

Now to the most important part – to include the typescript task into the workflow. You can simply do this by including it in the init task next to the clean step. This pretty much includes in all workflow commands defined in this particular Gruntfile.

grunt.registerTask('init', [
'clean',
'typescript',
...
]);

Similarly you can include the test file compilation into the test task.

grunt.registerTask('test', [
...
'clean',
'typescript:test',
...
]);

We are just not yet done though. In the original Gruntfile.js that was created, there is a task to copy all files from the source folder to the distribution folder. When we included the typescript task that moves the .js files, the copy task became redundant for the scripts folder. We need to fix this by excluding the scripts folder. Once you make the change your copy.app config should look like this.

As you can see we have also made sure that no .ts or .d.ts files are copied to the distribution folder as well.

Now you can go ahead and create .ts files in your scripts folder. However to compile them successfully we need to do one more thing.

TypeScript Definitions for JS libraries

Though we are writing our new code in TypeScript, most of the framework code such as Angular and Ionic are written in JavaScript. The TypeScript compiler wont be able to recognize the symbols and resources we use which are from the JS libraries. Don’t panic – we have bunch of awesome people who have created us DefinitelyTyped just for this reason. It’s a repository of TypeScript definition files for the popular JavaScript frameworks and libraries.

We need to include the TypeScript definitions for Angular, Ionic and Cordova for us to be able to use them. We don’t want to go ahead and include all DefinitelyTyped definitions, instead they themselves provide this handy tool TSD which will let you add definitions (just like NPM or Bower packages). Are we living in an awesome time or what?!

Lets first install TSD using NPM

npm install tsd -g

Now while you are in your project folder initialize TSD in your project by issuing the following command. This will create a tsd.json file where you can save all the definitions you install for later reinstall (just like NPM).

tsd init

The tsd.json file also contains the path you want to store the definition files. I would suggest putting them into your source scripts folder to fit our above configuration. In this example we have created a folder named typings.

Mutual empathy is a feature of any successful relationship, may it be romantic, family or professional. It is more crucial in some relationship than others. The importance of this skill for a leader is quite critical.

Just think about it, how does it make you feel when someone just “gets” you. It makes your life simpler and makes you feel comfortable around that person. As a leader it is essential for you to keep your subordinates comfortable and concern free. People are productive and perform the best when their minds are cleared of any concern or worry and empathizing with them will help you as a leader to clear their concerns, solve their problems and help them see things clearly. So how does empathy work?

Listen to what they say

To understand is to first know. If you don’t know then you never will understand. The gap between knowing something and understanding it well is effective communication. People may not always talk about concerns/problems or worries they have. But when they do, listening to them and devoting the time to it should be the highest priority in your list as a leader. Selflessly involve yourself in their concern and care about it. Try hard to understand their situation. There may be a thousand other things on your plate but this comes first.

Make it easier for them to talk

It’s not easy for someone to talk to you about their concern, may it be professional or personal. It is your duty to make them feel you are there if they want to do so. The relationship you build with your subordinate creates and facilitates the climate for this. The culture and environment in your team plays an important role. You have to constantly assure directly or indirectly that you care and want to help.

Listen to what they don’t say

You need to constantly pay attention to the behavior of your subordinates. There are people who talk and there are those who don’t. Some naturally exhibit their concerns and worries through different behavioral traits, negative or positive. Though perceiving this is not an easy task, it’s important to pay attention. You should be careful not to assume the scenario based on behavior but this serves as an important channel to initiate communication. Little differences in people’s behavior will tell you that something is not right.

Sometimes people try to communicate indirectly. If you are not paying attention you may never know and they may never want to try again. This too serves as a great channel to initiate communication.

Put yourself in their shoes

It doesn’t matter how much you communicate with someone. If you are not trying to understand the situation being in their shoes you are not really empathizing. Imagination is important. Every other person thinks different and understands the world around them differently. This may be due to their culture, exposure/experiences, beliefs and other factors. You as a leader have to take the effort to imagine, see and feel what they do as people. You are probably never going to see it or feel it exactly the way they do, but the amount of effort you put in understanding and imagining may take you close to what they see and feel.

Acquiring the skill

Is empathy really a skill, and can it be acquired? Yes it can. For some people it comes naturally, but like any other skill practicing is the key to acquiring this one as well. It requires an undivided level of patience and care to constantly practice this. It is a difficult thing to practice if you are not good at it. You need to keep remembering to pay attention, listen and spend time on the relationship. It may take a long period of time to be good at it but constantly practicing is the key.

Empathy is probably the most important and most difficult people skill a leader must have. So don’t give up!

The term WDS (Wireless Distribution System) might be a familiar one if you have meddled with standard wifi routers/access points that are available nowadays. The concept is quite simple – the system enables the router/access point to act as a bridge or a repeater. Now as simple as it may sound, trying to get WDS working to extend your wifi network or to bridge your wifi to a wired network is not considered nearly as easy as it sounds.

It all started when I wanted to extend my home wifi network to the living room where I have my NAS and an Android based device running XBMC, both of which don’t have wifi capability. So I needed the wifi to be bridged to enable a wired network as well. Since the signal in the living room wasn’t great, extending the wifi made sense. What better than using one of the old routers I already had, to get this done right? So began the hunt for a hack. The more I looked on the internet I could not get a simple set of instructions which told me how to get this done. There were many articles elaborating on the concept like this one but nothing clearly said how to do it. Yet alone most of the discussions suggested the setting up WDS was most unlikely under many different conditions.

I had to give it a shot. So I took out three different models of the old routers I had and started messing with them. Changing the settings on them and trying different levels of changes to get them working. It didn’t take long before I could get a elaborate setup working that utilized WDS. However this was quite tricky and I picked up a few things on the way. So here it goes.

Following tips are based on the assumption that two routers/access points are used to extend and bridge a wireless network. Both devices are expected to have WDS capability.

1. Set the IP of both devices in the same subnet

Set static IP’s for both devices which belong to the same subnet. If you set the main device (lets call it AP1) to have the IP 192.168.1.1, you can set the secondary device (lets call it AP2) to have the IP 192.168.1.2 or something similar. In this case we will setup AP2 to extend the network from AP1.

2. Setup only one DHCP server

If you require a DHCP server in your network it should ideally be setup on AP1. Disable the DHCP server on AP2. If AP2 supports DHCP relay, you may want to switch that on. Once you’re done with the full setup, one DHCP server should be able to assign and manage IP’s for all devices in the network.

3. Enable wifi and set the SSID

Enable wifi on both AP1 and AP2. The SSID of both AP1 and AP2 can be same or different. This doesn’t really affect the WDS setup since WDS uses your BSSID (the MAC address) to identify the devices. This decision depends on how you want to identify your network. If you want the wifi repeating to be smooth and you actually want to see your whole network with one SSID then you set the same SSID on both AP1 and AP2. If you want to identify AP1 and AP2 separately then you would want to assign two different SSIDs. What I did was have different SSID’s when setting up the network and then once I was done I switched both AP’s to the same SSID.

4. Set your wifi security to WEP

Set the wifi security on both AP1 and AP2 to use WEP. Also set the authentication to Open Authentication with a 128bit encryption. The authentication keys on both APs must be exactly the same. It’s essential that all settings be exactly the same on both APs.

5. Other wifi settings

Like I said, successfully setting up WDS to work means matching the settings on both AP’s to work the exact same way. If you have problems in getting WDS to work this is one area you can explore and tweak. As a thumb rule avoid having settings that are not absolute and can change. What I mean here is settings that are set to “Auto” or set to a range of values from which the AP can decide to choose such as “802.11b/g/n”. Following are a few of wifi settings you have to look into.

Wifi Mode – The mode has to be same on both APs and must be an exact value which is either 802.11g or 802.11n. If all your devices and both the APs fully support 802.11n, you can go ahead with that. However if you have difficulties getting it to work you can switch to 802.11g which has a better chance of working

Channel – The channel has to be the same. Having the channel set to Auto is not going to work. You can use a tool to check which channels have the minimum interference in your environment and pick the best channel. Set the channel to the same value on both AP’s.

Transmit Power – This shouldn’t ideally affect, however having this set to 100% on both AP’s will let you achieve the best range.

6. Set the WDS settings

Enable WDS on both APs. Depending on the device rest of the settings can vary. It essentially boils down to assigning the MAC address/BSSID of the devices to one another in the WDS settings. So in the WDS settings of AP1, you will need to assign the BSSID of AP2 and in the WDS settings of AP2, you will need to assign the BSSID of AP1. Different devices allow you to do this in different ways. You might see one of the following methods in each of you AP’s WDS settings.

You may have to select the SSID of the other AP from a list (upon scanning for available networks).

You may have to select the SSID of the other AP from a list which will reveal the BSSID.

You may have to type in the SSID of the other AP

You may have to type in the BSSID of the other AP

If either of your AP’s use method 1 or similar, you may have to have different SSID’s for AP1 and AP2 to ensure you can select them.

7. Set the correct security settings for WDS

Some devices require you to select the wifi security settings when setting up WDS. If this is the case you will need to put in the exact same settings you did in tip 4.

8. Don’t keep the APs too close to each other

When you are setting up the APs try and keep them away from each other. Keeping the APs too close to each other can cause interference which may not let either of the APs to perform.

There may be other factors that matter when it comes to setting up your WDS which I would love to know about as well. If you do find any other tips that may be useful please write them in comments section. Hope this helps someone save some time 🙂

Drawing network diagrams can be quite helpful when setting up even a simple network. Creately can be a very useful tool for drawing network diagrams. Give it a shot, its free to use.

I have been receiving few emails from a guy about some book order. First time I saw it naturally my thought was SPAM. However today when I go a message from the same guy I had a proper look at it since it was showing up on my “Primary” mailbox again. It actually is a mail that is supposed to go to some guy/girl who has the address “hira.ash@gmail.com”. Now I own an email address which is pretty much the same but without the dot (.) in the middle. I have the mail forwarded from that particular account to my current email address.

It seems like this particular person has mailed someone about a book on the classified site http://www.kijiji.ca. The seller however when replied to the mail saying its not available it landed in my inbox. Today I got another reply saying the book is available for $45. Now the craziest thing out of all this is that the to address of both of these mails show as “hira.ash@gmail.com” which is not my email address.

I have just reported this to google and also forwarded the mail to the address that is supposed to receive it. Below is the email trail and the mail detail which shows the to address.

The mail trail:

The to address:

This is quite a scary thing to see! I sure hope my email is not lading in someone else’s mailbox!!

UPDATE:

I think I was too soon to post this. As I searched I found the following article which clearly mentions that Gmail does not recognise dots(.). This clearly means that someone has misspelt their email address.