Neil Loknath

Freeze Dance - Entertain Your Kids, Hands-free

Fri, 21 Feb 2020 10:25:24 -0500

Freeze Dance for iOS

Freeze Dance is a simple app for a super, fun game.

Open the app, press play, and that’s all there is to it. Freeze Dance will begin playing music from your queue in Apple Music. Dance until the music stops. Then, freeze and hold your position until the music plays again. Great game to play with kids and adults of all ages.

This app was born out of my desire to reduce the small cognitive load required to pause and unpause music while playing this game with my toddler. I know, first world problems, right? But, let’s face it. Every little bit helps when raising a toddler. I found it annoying to have to find the pause/play button every time I wanted to toggle the music playback. It was distracting me to having fun with with my daugher. This app really helps. She loves watching the timer countdown, and even has a blast saying the numbers while she’s dancing.

Features

Integrates seamlessly with Apple Music
Game stops when app is in the background
Use Apple Music app to update the play queue
Light & Dark mode compatible
Randomizes dance and freeze duration
Large, clear countdown timer
Keeps screen on so timer is always visible

Benefits

Movement helps develop muscles, coordination, and keep joints flexible.
Being able to listen and process sounds while tuning out background noise helps children strengthen their ability to receive, organize and interpret auditory input.
The ability to hold a position (static balance) and the ability to maintain balance when moving (dynamic balance) are necessary life skills for everyday activities

Download

The best part is it's free! Download it from the App Store today. It'll be ad-free for a limited time.

The Best Perk Is A Great Development Culture

Sun, 26 Jun 2016 11:25:24 -0400

What makes a great development culture? Free drinks? Free breakfast? Everyday happy hour? Sure, those things are attractive. But, cool perks are par for the course these days. Virtually every startup and their uncle with a round of funding have perks of some sort. So, if perks are ubiquitous, there must be more to a great development culture than perks.

I’ve been a Developer, a Team Lead, and now a Manager at Achievers. Throughout my career there, I’ve been exposed to many habits and behaviours that have really influenced my own day-to-day happiness and engagement. When writing this piece, I took a step back and really thought about what I’ve valued during my career working as a developer. From that perspective, I’d like to recommend a few ideas that I believe will help you achieve and maintain a development culture where happy, engaged teams can thrive.

Why Is As Important As What

Software developers are problem solvers at heart. Taking a problem, coding up a solution, and seeing it through into production is definitely satisfying. But, what’s even more satisfying is knowing that the solution being implemented is the best one possible.

Educate your teams about business problems, usability concerns, and feature ideas. Engage your teams in the brainstorming process. Express why a given problem is a problem and why it’s the current priority. Knowing the why can inspire new and better solutions.

Everyone Is A Product Owner

If you’re working in Agile, you probably have a Product Owner for each feature or team. While the Product Owner has their own set of duties and responsibilities, I like to think of the entire team as being product owners because every individual contributes to the delivery of the final product.

Each person has their own unique set of values enabling them to think in their own unique ways. Encouraging a sense of ownership in everyone by seeking input from the team in all phases of development results in a sincere desire to improve the product, different perspectives, fresh ideas, and improved features.

Silos Are For Farmers

Frequently, teams are organized by feature or skill set. Either way, this doesn’t mean that the things they own should be the only things they do. Sometimes, a team will require a change to a feature, service, layer, etc. owned by another team. There’s a few choices: delegate the work to the owning team and let them prioritize the work within their current set of priorities (or negotiate new priorities), take on the work yourself, or don’t do the work at all. All of these are viable options. But, the second is one that shouldn’t be overlooked. Taking on work you don’t normally do is a great way to collaborate, stay challenged, and learn new skills. Don’t funnel developers into silos. Give them the freedom to contribute outside of their comfort zone. They will be grateful.

Trust Your Talent

Software developers are smart people. They’ve been hired for a reason. They’re experts in their domain. Let them be experts and do what they do best. Smart people need the autonomy to learn, think, question, break things, and put them back together until the right solutions present themselves. Very often, if given a little direction and time, they’ll get the job done. Developers — especially developers — don’t particularly enjoy being micromanaged.

Celebrate Success

Software is built by people for people. The end goal should be that the people you’re building your software for will fall in love with it. And, when they do, share those success stories with your development teams. As a developer, realizing the value the features you’re building are bringing to your customers can be very inspiring.

When you can get software into your customers’ hands as quickly as possible, the results are even better. Employ Continuous Delivery (easier said than done, of course) to shrink your feedback cycle and create more opportunities to celebrate success. The benefits from continuous delivery are too great to write about here, but it’s worth mentioning that seeing the code that you write go live daily is very empowering. Moving to continuous delivery has been one of the best experiences of my career.

Success is an important component, and it’s something that can be realized even before you’ve gone to market with your product or features. Take the time to allow teams to showcase in progress work, so that they can provide visibility to the challenges they’ve faced and overcome. They’ll get a chance to feel that sense of pride everyone feels when showing off a great achievement, and stakeholders will get iterative glimpses into the future value being created.

Evolve Everything

Create an environment where everything is evolving. A product should evolve, but the people building it should evolve with it. Constant learning is key to maintaining a team that feels challenged and grows.

Many developers enjoy sharing what they’ve learned in their coding journeys. Facilitating sharing by creating opportunities for developer hosted learning sessions whether through meetings, meet-ups, blogs, or presentations allows those developers to shine and grow skills within the team at the same time.

As the product and people evolve, processes grow stale and need to evolve too. Development processes shouldn’t be set in stone. Let your teams have input into what doesn’t work and work together to improve things.

Look Beyond Features

You could argue that being innovative through investing in creative solutions while developing features is innovation at its best. And, that argument is a good one. However, you’ll likely find that your developers will want more. I think that’s more than OK, and it’s actually quite healthy. Being part of a team full of developers that want to be creative is a good problem to have. Give them a creative outlet. That could be hackathons, 20% time, innovation sprints, or something completely different. You could try planning for innovation as part of the normal sprint planning process, for example. This has the benefit of continuing feature and experimental development concurrently instead of punting things down the road.

Use appropriate tools to facilitate the creative process. We use Slack quite heavily, as it’s a great way to carry on constant communication about new ideas. And, as I mentioned above, no process should be set in stone. It’s a big plus to have the freedom to innovate on your development processes as well.

Say Thank You

Most importantly, say thank you. Say, great work. Say, you’re awesome. Say it and mean it. Simple.

Happiness Is The Best Perk

While not an exhaustive list, the above ideas will go a long way to building a culture where developers can not only provide value in many different ways, but feel they’re providing value as well. Happy teams are teams that can understand why their contributions have an impact. When they can contribute to the entire development process all the way from ideation to delivery, they’ll develop a heightened sense of product ownership, and therefore feel a strong desire to improve things.

Cultivating good habits in an organization comes much easier when you have the right people on board. Speaking from my own experience, particularly at Achievers, I’m grateful to have been surrounded by great people. Working in an environment with this kind of culture has been very inspiring. Work towards living the behaviours I’ve recommended in your teams, and you’ll be well on your way to a development culture that goes well beyond cool perks.

(Originally posted on Medium.com)

These Thumbs Aren't Made For Scrolling

Sun, 11 Jan 2015 17:01:24 -0500

Collapsible interfaces are great. Bootstrap’s Collapse element comes to mind. As does Wikipedia’s collapsible sections you get when viewing from a Mobile. They make it simple to compact a lot of information into a small space. They allow you to easily jump around a document giving you the choice of expanding one section at a time so less scrolling is required. But, what happens when you want to make things compact again? What if you’ve expanded something, scrolled through it, and now want to move on to another section? You have to either scroll all the way back to the top or bottom of the section, depending on which direction you want to go. This can really make for some tired thumbs on a mobile device.

Sure, we could implement one of those trendy scroll-to-top arrows. That at least let’s you work your way up. But, what about the other direction? I think we can do better.

Below, on the left, you’ll find the usual collapsing section user experience you know and love. On the right, you’ll find the same interface with a subtle improvement.

Without Improvement

Your browser sucks.

With Improvement (ironically, this may not behave correctly on mobile due to being an iframe)

Your browser sucks.

You’ll notice that the one of the right let’s you collapse the section you’re browsing even after you’ve zoomed past its title. This lets you move up and down without the thumb workout. The title also shinks a bit to give you that little bit of extra real estate. Pretty nifty, eh?

App Sale!

Tue, 14 Jan 2014 20:46:00 -0500

It’s a post-Christmas, post-Boxing Day (for my fellow Canadians), late to the party, app sale!

Ticklebug Pro is on sale for 50% off. Get it now for only $1.49! Ticklebug is a super smart and simple Android app that lets you remote control your Windows and Mac computers from the comfort of your mobile device.

Pictures are better than words, and videos are better than pictures. So, take a look and see what Ticklebug can do.

Hue: Your Color Expert

Wed, 08 Jan 2014 23:13:00 -0500

Inspired by the flurry of I built x apps this year posts over the holidays, I decided I would make 1 app in 1 weekend. I took an idea and ran with it. Pushing myself to get it done in 2 days forced me to keep it focused and cut out unnecessay things.

I’d like you introduce you to the result of my weekend hackathon, Hue.

Hue is an Android app based on a simple premise: it should be easy to browse a large variety of colors and view a large variety of colors that are very likely to go well with a certain color.

Hue gives you you get an endless stream of colors to choose from. Want more colors? just keep scrolling.

Tapping a color presents you with a another stream of different color schemes created algorithmically based on rules of color theory.

Viewing schemes also lets you tap colors to learn about their HEX code, RGB & HSV values, and even sample tints, shades, and complement colors.

Beauty is in the eye of the beholder. Thus, Hue tries to present you with a wide selection of schemes combining tints, shades, complements, analogous, and neutral colors.

Hue does a great job. Regardless, nobody is perfect. So, there’s a solution for this problem too. Tapping the Share button at the bottom of the schemes view lets you export an HTML page containing all the schemes created for your chosen color. If you’re a designer, developer, or just a tech savvy kind of person, this is great because you can use your browser to further tweak and experiment with colors.

Hue is great for brainstorming color schemes whether you’re painting, redecorating, designing a website, or even planning your wardrobe. It’s available in the Google Play store for only $0.99.

In Private

Mon, 14 Oct 2013 21:45:00 -0400

This blog and the entire site are now only accessible using HTTPS.

Why

The reasons why I did this are fairly simple:

I read this.
And, I completely, 100% agree.

How

I got my SSL certificate from StartSSL for free. They verified that my site is really run by me in a matter of minutes. I moved my site from NearlyFreeSpeech (nothing against them, as they were nothing but fantastic during the many years my blog was hosted there) to my VPS. This gave me full control over things and allowed me to configure Apache to use SSL.

If you try to go to http://www.nloko.ca or http://nloko.ca or http://www.nloko.ca/anywhere you will be redirected to the same URL with the scheme changed from HTTP to HTTPS.

Privacy by Default

This has nothing to do with secrecy. It’s about your right to browse content on the Internet in private without anyone else listening in. If you host a website, I urge you to consider making it private by default.

Ticklebug

Mon, 22 Apr 2013 22:57:00 -0400

I created Ticklebug to solve a problem for myself, and I’ve decided to share it.

Ticklebug was born as result of saying goodbye to cable subscription fees in our home. Bye, bye fees. Bye, bye cablebox. And, Hello, HTPC!

The Need

Obviously, I wasn’t going to be walking up to the television set to fiddle around with a keyboard and mouse everytime I wanted to watch something. That would be way too much exercise for something that’s really supposed to involve as little exercise as possible. Initially, my solution for this problem was one of those wireless keyboards with an integrated trackball. Don’t get me wrong, the combination is pretty awesome. After awhile, though, I noticed that I was playing with my phone a lot of the time while watching TV. So, I thought it’d be great if I could use my phone as a remote control!

I began searching for and trying various Android apps for remote controlling my HTPC. However, I wasn’t completely happy with any of them. In my ideal remote control app, I wanted the following features:

A maximum surface, blank canvas that acts like a touchpad, very similar to how laptop touchpads behave.
Mac and Windows support, as I use both regularly.
Voice commands so I can tell my computer what I want it to do.
Zoom! Because, as great as high-def is, sometimes things are just hard to read.

Features

Ticklebug has a long list of features, so I won’t go over everything. What I will do, though, is I’ll go over the above list and tell you a little about how Ticklebug handles each.

Touchpad

Ticklebug maximizes your mobile device’s screen space keeping it uncluttered at all times. There are a very limited number of buttons. To interact, touches, drags, and taps are used liberally. To make Ticklebug super easy to use, the gestures are very familiar:

Drag a finger to move the mouse pointer
Drag two fingers to scroll within windows
Long-press a finger and drag to move or resize windows
Single-tap to left click and double-finger-tap to right click
Swipe left or right to navigate back or forward, respectively, when web browsing

Cross-platform

I use a Macbook most of the time. But, my HTPC runs Windows 8. I’m a faithful subscriber to Netflix, and running Windows just makes using the service much easier than using another operating system. Thus, I needed Ticklebug to be cross-platform to get the most out of it. As a result, there are desktop applications for both Mac and Windows.

Voice Commands

What’s cooler than speaking instructions to your computer? Nothing! So, I gave Ticklebug the smarts to understand a few commands:

Say Google followed by some search words and your default browser will load with the search terms ready to go in Google’s search bar.
Say Open followed by some site name and your default browser will load it. For example, say open youtube dot com, and http://youtube.com wlll load.

And, in the paid version of Ticklebug:

Say Start followed by the name of some executable file, and your computer will run it. For example, say start notepad, and Notepad will start.

What’s great about the last command is that you can create your own voice commands to do just about anything! For example, on Windows 8, Netflix has some weird, wild, hidden file name making it difficult to launch using a voice command. However, the application will run if you type netflix:// into a browser. We can use this piece of information to create a custom voice command.

On my computer, I’ve created a script named netflix.bat and saved it in a directory that’s specified in my PATH environment variable. The contents look like the following:

:: Launch Netflix app on Windows 8
cmd /c "start netflix://"
exit 0

Now, I can say start Netflix to launch the app without typing a thing!

Pinch-to-zoom

Again, using Netflix as the example, those little video thunbnails in the Windows 8 app are pretty hard to read most of the time. I really wanted to be able to zoom in the way you can when using your phone’s web browser. So, in Ticklebug, you can move two fingers apart to zoom in and move two fingers together to zoom out. And, this gesture can be used within any application, including the desktop.

In Stores Now!

If you have an Android device running Android 4.0 or higher, give Ticklebug a try!

No Comment

Sat, 30 Mar 2013 14:36:00 -0400

I was always taught in school to liberally apply comments to my code. For a long time, I considering this practice a good one. I no longer do, however.

Before you write me off as a lame-o programmer, to illustrate why I feel this way, let’s walkthrough some examples using an old favourite algorithm: merge sort. For the sake of this exercise, though, let’s assume that merge sort is not a widely known algorithm, so we don’t fall into the it’s merge sort, duh! trap.

def mergesort(a):
	if len(a) <= 1:
		return a
	m = len(a) / 2
	l = a[:m]
	r = a[m:]
	return merge(mergesort(l), mergesort(r))

def merge(l, r):
	li = 0
	ri = 0
	m = []
	while li < len(l) and ri < len(r):
		if l[li] < r[ri]:
			m.append(l[li])
			li += 1
		else:
			m.append(r[ri])
			ri += 1
	if li < len(l):
		m.extend(l[li:])
	else:
		m.extend(r[ri:])
	return m

Here we have a completely correct sorting algorithm coded in one of my favourite languages, Python. In my opinion, though, correct code is not quite good enough. This code could be improved in some ways. Let’s assume that liberally adding comments is one of these ways.

def mergesort(a):
	"""Returns a sorted list.
	"""
	# Base case for recursive algorithm is when
	# there is 1 or less elements. In either case, we call 
	# the list sorted.
	if len(a) <= 1:
		return a
	# Find the middle of the list
	m = len(a) / 2
	# Split the list into halves
	l = a[:m]
	r = a[m:]
	# Merge the two sorted halves 
	return merge(mergesort(l), mergesort(r))

def merge(l, r):
	"""Returns a merged sorted list.
	"""
	# Track the positions of the lists starting at index 0
	li = 0
	ri = 0
	# Initialize an empty list to store the final sorted list
	m = []
	# Loop while both halves still have unprocessed elements
	while li < len(l) and ri < len(r):
		# When the left list element is less than the right
		# list element, we add it to the final sorted list
		# and increment the position for the left side. Otherwise
		# we do it for the right side
		if l[li] < r[ri]:
			m.append(l[li])
			li += 1
		else:
			m.append(r[ri])
			ri += 1
	# Since one list has been completely processed, we extend
	# the final sorted list with the sorted elements remaining in
	# the other list
	if li < len(l):
		m.extend(l[li:])
	else:
		m.extend(r[ri:])
	return m

My once Intro to Algorithms professor would really like this version. But, you, however, shouldn’t like this. Let me explain.

Since I’m assuming that merge sort is an unknown algorithm, in an effort to improve readability, I’ve added lots of prologue comments. They basically reiterate what the code is doing. To me, these types of comments add too much clutter and may over-complicate something that wasn’t all that complicated to begin with (like in this case). For a college professor receiving something like this from a student as an assignment, these comments could be useful, as they could give insight into whether or not a student understands what the code is doing. However, in a work setting, it should be a fair assumption that your colleagues can read the code to figure out what the code is doing.

It could be argued, though, that without the prologue comments, the readability is suffering because the variable names don’t convey enough about the code. That’s a valid point. So, let’s try something different.

def mergesort(unsorted):
	"""Returns a sorted list. 

	The passed list is recursively halved 
	into sublists until each sublist has one or less elements. Then, 
	the sublists are merged together such that their elements are in order.

	Worst case time complexity is O(n log n).
	Worst case space complexity is O(n).
	"""
	if len(unsorted) <= 1:
		return unsorted
	
	middle = len(unsorted) / 2
	left_half = unsorted[:middle]
	right_half = unsorted[middle:]
	
	return merge(mergesort(left_half), mergesort(right_half))

def merge(left, right):
	"""Returns a sorted list as a result of merging 
	two sorted lists.
	"""
	left_index = right_index = 0
	merged = []
	
	while left_index < len(left) and right_index < len(right):
		if left[left_index] < right[right_index]:
			merged.append(left[left_index])
			left_index += 1
		else:
			merged.append(right[right_index])
			right_index += 1
	
	left_remaining = left_index < len(left)
	if left_remaining:
		merged.extend(left[left_index:])
	else:
		merged.extend(right[right_index:])
	
	return merged

This version follows the no comment is the best comment approach. The variable names have been modified (and according to Python style guidelines) to convey their purpose making the code self-documenting and rendering all the prologue comments unnecessary. The code itself effectively describes what the code is doing.

The function headers have been improved such that callers can discover what the functions do without reading a single line of code. This is especially important for public interfaces and let’s us use tools like pydoc to easily share code documentation.

You may be wondering, what’s the big deal? Let’s just refactor and keep the comments too so we can have the best of both worlds! The problem is that adding unnecessary comments creates another set of things to maintain. It’s even worse when the code changes and the comments are orphaned. Suppose a colleague comes along and changes the code again based on comments that incorrectly describe code that no longer exists. Now, things are really a mess. Then, your colleague goes on vacation and a bug surfaces related to all these changes and you’re stuck git bisect‘ing your way through it all to figure out where things went wrong! So, I’ll state this again very explicity: liberal code commenting is wasted effort; make your code more self-documenting because no comment is the best comment.

Moxy

Mon, 11 Feb 2013 21:23:02 -0500

She’s alive. And, her name is Moxy.

Simply put, Moxy is an HTTP proxy that acts like a regular HTTP proxy, but it also allows you to mock responses, including support for delays and conditional statements.

Why is this useful? Consider the following use case…

You’re working on a team of two. You’re responsible for the client code and the other handles the server side. Let’s call the other, Backend Billy. Backend Billy is great most of time. However, lately, he’s been a little distracted, affecting his ability to deliver on the RESTful API that you need to get on with your client side work. Of course, being a good team, you spec out the API beforehand and have an interface to work against. You’ve got a bunch of code written up, but you can’t test real, live network requests because the API service doesn’t exist yet. Moxy can help here.

Let’s say you’ve spec’d out three endpoints…

http://api.awesomeapp.com/v1/awesome http://api.awesomeapp.com/v1/awesome/add http://api.awesomeapp.com/v1/awesome/:id

Using Moxy, you can add the following configuration entries into moxy.conf…

url http://api.awesomeapp.com/v1/awesome/?$
  get 200 awesome.json

url http://api.awesomeapp.com/v1/awesome/add
  get 400 awesome_add_error.json
  post 200 awesome_add.json

url http://api.awesomeapp.com/v1/awesome/?\?id\=.+
  get 400 awesome_id_error.json
  if created: get 200 awesome_id.json

Now, with Moxy up and running and your system configured to use her as an HTTP proxy, you can happily test your client code as if the backend is fully implemented, even though Backend Billy is still dilly dallying.

Notice the line that reads if created: get 200 awesome_thing.html. It’s a conditional statement with a condition called created. This allows the success response to be delayed until necessary. You can see and manipulate all conditions by browsing http://localhost:9889/config/conditions.

Additionally, let’s say you’ve added some nifty error handling logic when the add request takes longer than 10 seconds. To test, you can modify moxy.conf as follows…

url http://api.awesomeapp.com/v1/awesome/add
  if delay: delay 13000
  get 400 awesome_add_error.json
  post 200 awesome_add.json

This tells Moxy to delay the response for 13 seconds if the delay condition evaluates to true.

And, if none of that interests you and you just want Billy to get back to work, you could sneak on to his computer and configure Moxy with something like…

url ^.+\.facebook\.com
  get 301
  header Location http://awesomeapp.com/api/documentation

Moxy is written in Python, open source, and available on Github.

SyncMyPix 0.2

Sat, 20 Oct 2012 04:01:37 -0400

Remember SyncMyPix?!?

I do…vaguely. I’ve been putting off integrating some fine work from contributors, and I figured that it’s been long enough!.

I’ve finally gotten around to merging in their work creating version 0.2. Here’s a quick summary of what’s gone into this release:

Update contributors in README
Remove read log permission
Default to high quality photo setting and remove setting
Fix problem with photos not getting cached to SD card
Improve Greek name matching (thanks Diomidis Spinellis)
Fix name matching when names contain Turkish characters (thanks Deadknight)
ICS fixes (crop view, etc.)
Use Facebook Connect SDK instead of homegrown API library
Attempt to get highest resolution photos possible from Facebook

Those last 3 are also thanks to Deadknight.

Unfortunately, I haven’t had any time to work on SyncMyPix, hence the delay with getting out a release with all these improvements. I’ve been quite busy with work and other projects. So busy, in fact, that I’m calling this my last release of SyncMyPix. I haven’t tested this enough to feel comfortable releasing it through the market (I actually did publish it, but later removed it). But, I didn’t want that to stop me from sharing this, so the downloads are available from Github. I’m going to be removing SyncMyPix from the store a week from today.

I’m glad it’s been useful to a lot of people, but I’ve got to move on to other things. I’ll continue to host the source code on Github, as I’d love to see someone take the app and improve on it, as it seems there are still people that are interested. So, please, feel free to fork it and make it your own!