June 2015 – Tech leadership

Delegated authentication

Over the next few days we are going to talk about delegated authentication. For modern standards this falls under “What you know”. See What is authentication for further discussion.

To illustrate what delegated authentication is we will start with an all too common story. We introduce you to Mary

Mary loves social media, uploading her pictures on facebook, instagram and then tweeting them. However she is a very busy lady and does not like the work of uploading the same file to multiple servers.

As a tech savvy developer eager to impress your skills on her, you figure you can help her automate this task. The most easiest way forward would be to ask her for passwords for her three accounts then, when she uploaded a picture to your service, your service would automatically post it on all three platforms.

You immediately hit a snag with this approach, as it turns out Mary is not particularly fond of giving her password out to strangers no matter how tech savvy!

On further inspection you find out this is because she is afraid you will not only post the photos she has instructed you to, you will also go through her other stuff.

But what if you could assure her that you need access to posting photos only and not to the rest of her stuff. Prior to 2006 this just wasn’t possible but today that is exactly what delegated authentication does.

In delegated authentication you are the owner but not the direct consumer of a certain resource. To continue we must first define some key terms used in this paradigm.

Resource: A digital activity or data in our case this would be posting the photo
Delegator: This is the owner of the resource in our case here, that would be Mary
Delegate: The delegate wants to access the resource
Service provider: Hosts the resource and validates legitimacy of the delegate

It is entirely possible to build out your own delegated authentication service, however you are likely to run into interoperability problems pretty quickly. Thankfully there exists standards for this kind of authentication we will be speaking about in a later entry.

Signup to make sure you don’t miss it.

Have you ever been in the same situation as out tech savvy developer? How did you handle it? Talk to us in the comments below.

Common implementations of MVC pattern

As far as design patterns go, MVC is the most well known pattern.

Model

This component contains the data structures and logic that are unique to your business. That is what the application does to add value.

Examples of this would be your firebase models.

View

This component interacts with the users of the application.An example would be the html rendered in the browser.

Ideally, the view should listen for changes in the model and respond to them.Most modern Javascript frameworks allow you to do this.

Controller

The controller processes requests incoming from the user and sends them to the model as commands.

Of course the pattern is a general principal. To its end a couple of popular implementations have emerged which we will look into in brief.

Configurator/Actor

In this pattern the controller writes out a request to shared file such as a dot file. A daemon running in the background would then read this file and perform an activity based on it.

Spooler/Daemon

This particular pattern is best illustrated by the print spool. The front end (your machine) drops files to be printed in a spool area. A printer daemon running in the background watches for new files and send them out to the printer. Once the job is done, the file is removed from the spool area.

It is noteworthy that this pattern would work well with jobs that would benefit from batch processing.

Driver/Engine

In this pattern the driver provides commands and interprets output from an engine after startup. An example of this would be where a utility meant to periodically fetch content from say ten different websites starts up curl in the background and uses it to do the actual fetching.

Client/Server

This is the browser/server pair where requests are sent to a daemon running in the server such as nginx which then processes the request and sends a response back.

This pattern can be thought of as an implementation of the Driver/Engine pattern.

Do you know of any other implementation of the MVC pattern? Talk to us in the comment section below

Simple Software Estimation

Estimating how long it will take you to write software is a crucial yet often ignored skill. No matter the size of the project, it’s good to get into the habit of estimating your projects.

You don’t really need a complex system to achieve this. Here is a sample of a simple spreadsheet to get things of the ground.

Simple Estimation

This method was borrowed from Joel Spolsky book http://www.amazon.com/Joel-Software-Occasionally-Developers-Designers/dp/1590593898/

Some important points to note concerning software estimation:

KISS

As usual we are back to our beloved principle, your estimation platform should be as simple as you can make it. That is tasks should be as fine grained as reasonably possible. You should be thinking in tasks lasting 30 mins to at most 2 hours. In short a coding session.

It’s possible that you have longer coding sessions but I still believe you should keep it to this chunks.

Let the developer do it

There is evidence that letting people set their own schedules leads to boosts in productivity. Below is the findings of research carried out by Lawrence and Jeffrey from the University of New Wales. http://www.amazon.com/Programming-Productivity-Mcgraw-Hill-Engineering-Technology/dp/0070328110

Programmer Productivity

Of course there is a caveat to this general rule as can be seen above, system analysts generally give better estimates. This is because they have more estimating experience. Still unless you have the budget for a system analyst, stick to the rule.

This is a living file

The column Curr Estimate and Elapsed time should be continuously updated. It is my suggestion that you take 10 mins after your coding session to update this values.

When you start of, your estimates are likely to be spectacularly wrong, however, if you discipline yourself to always update the estimates you will slowly but surely get better at this task as you learn from your mistakes and hone your estimating skills.

Version your estimates

It is critical that your estimates are part of the source. Whenever you commit your code, ensure there is a csv with your estimates within your project.

This gives you an opportune time to actually update your estimates before a commit as well as help you track the time used over long periods.

Tracking time

On this item you can either decide to use a time tracking software such as Toggl or use general estimates based on time spent.

This really is a matter of personal choice though you should strongly consider time tracking software if you or your agency bill by the hour.

Other considerations

It is important that you include other items that affect the schedule but are not programming tasks, this would include:

vacation and family time
debugging time
buffer time
deployment time

I hope I have been able to show the importance of scheduling and a simple way of achieving it. If you agree or have an even better method, share with us on the comments below.