All posts by J Stassen

7 Ways to Get More Likes on Instagram

Starting out on Instagram is tough. I’m still building my following. I’ve figured out a couple of patterns that are best to follow when posting to get more engagement on posts. Here are 7 ways to get more likes on Instagram that I’ve found.

Post in the early morning, or the evening.

People tend are busy during the day, they check their feeds either when they are getting ready for the day or after they are starting to wind down. Of the two, evening tends lead to a slightly better output.

Here I posted around 5pm.

Post at the best time for you audience.

Know your audience. If you’re posting a shot from a past trip to another country, try to match your post with when they are awake. Thinking about your audiences you might be able to get two audiences at the same time.

For instance, this shot is taken in Switzerland, I live in Chicago. I posted at 7am (morning) Chicago time 3pm (evening) Switzerland time. I hit both my local audience and my Europe audience.

Hashtag your post

I’ve seen many great photographers fail to put any hashtags on their posts. Hashtagging is a central feature of Instagram. It’s a key way for others find your post.

I follow the four Ws + D rule:
Where? (stmaryglacier, colorado) What? (mountains) How? (lensbaby, tiltshift) Doing? (hiking).

Use only hashtags that have posts

Being creative is good, but if you make up a new hashtag or hashtags that has few posts – No one will find your photo with that hashtag.

On this shot every hashtag here has at least 1,000 posts.

Hashtag in different languages

Hashtagging in other languages broadens the size of your audience. You don’t need to use obscure hashtags. I recommend using Wikipedia instead of Google Translate.

In this shot I looked up the article ‘Dragonfly’. On the left of Wikipedia you’ll see a list of the article in different languages.

Add a geo location

Every photo was shot somewhere. You can only set one location, but there might be duplicates of the location on Instagram. Before posting try to searching the location to see which one gets tagged with similar photos.

For instance here you can see I set the location for this post to Steamboat Resort.

Skiing in a wonderland. . . . #steamboat #winter #winterwonderland #snow #ski #skiing #colorado

A post shared by Sir.Nathan Stassen (@thebox193) on

Like back

When someone likes your photo, take a moment to scroll through their feed and like a photo or two, maybe leave a comment. But wait a few minutes before doing this. What you want is to pull them back to view your feed. They sometimes recognize your username / avatar and will view your feed to like more shots. You’ve invested in them, they will now invest time back in you.

Everyone that liked this shot, I liked at lest one of their photos back.

Comparing Immutable.Set() and Immutable.OrderedSet()

When comparing Immutable.Set() and Immutable.OrderedSet() you’ll need to convert the OderedSet down to just a plain Set.

Comparing Immutable.Set() and Immutable.OrderedSet()

To compare equality with a Set and OrderedSet use this:

mySet.equals( myOrderedSet.toSet() )

Immutable .equals() compares the left and right to decide if they are both Ordered. If one is ordered and the other is not, they are not equal. isOrdered(a) !== isOrdered(b).

My Feelings

I find this a bit odd, especially when the left is a plain Set. I feel regardless if the right is Ordered or not, it’s the contents that we’re interested in comparing. However this is the Immutable.js definition. You will need to downgraded the OrderedSet for comparison via .toSet() which does have a slight cost to it. Immutable performance is worth keeping an eye on.

Changing SourceTree’s Default Remote

I’m going to talk about changing SourceTree’s default remote.

When you’re pushing a new branch, SourceTree will automatically guess which remote you wish to push to by default.

SourceTree defaults to origin

By default SourceTree will always pick origin to push a new branch to. Depending on your workflow, you may want to set another remote as your default, let’s say my-fork for instance.

SourceTree defaults pushing new branches to origin

Renaming a remote

Interestingly all we have to do is rename our remotes. Since SourceTree always picks origin we just need to rename to anything else. Perhaps to the name of owner of the repo like SproutSocial or FaceBook. It’s safe to rename the remotes, it’s just a nickname only used locally.

(I’ve never been a fan of “origin“, it’s terribly confusing and ambiguous for those learning git).

Steps to rename the remote

via git

git remote rename origin SproutSocial

In SourceTree

  • Open the repo settings (gear in top right)
  • Remotes tab
  • Click on the remote
  • Edit
  • Change the Remote Name
SourceTree Remotes Setting
Editing remote names

Changing SourceTree’s Default Remote

Once we’ve renamed origin, SourceTree will always pick the remote that comes first alphabetically. So, do the ‘ol classic prefixed by numbers. Here I’ll name them 01-my-fork and 02-origin.

Boom! SourceTree picks 01-my-fork by default!

Changing SourceTree's Default Remote
Setting your preferred remote as default

Simple workflow optimizations like this, make me happy.

Pobierz za darmo easyHDR Preset

To jest mój pierwszy darmowy easyHDR preset dostępny do pobrania. Zapraszam do podzielenia się i odsyłania. Wkrótce zostaną wklejone zestawy ustawień.


Interior to Exterior 1 – jStassen


Ma na celu zrównoważenie realizmu skoncentrowanego na zewnątrz, a oświetlenie wnętrza wystarczy, aby nadać kontekst na scenie.


Free easyHDR preset download jstassen

Otwórz easyHDR

  1. Z menu kliknij pozycję Presety-> Reveal User Preset Files
  2. Umieszcza wszystie presety w tym folderze
  3. Zamknij i ponownie otwórz easyHDR

easyHDR Preset Download

This is my first easyHDR preset available to download. Feel free to share and link back. Preset bundles will be coming soon.

Zip File

Interior to Exterior 1 – jStassen

The Preset

The preset focuses on realism on the exterior, while illuminating the interior just enough to give context for the scene.


Free easyHDR preset download jstassen
easyHDR preset Interior to Exterior 1 – jStassen

Install the easyHDR Preset

  1. Open easyHDR
  2. From the menu click Presets-> Reveal User Preset Files
  3. Places all presets into this folder
  4. Close & re-open easyHDR


Pagination naming conventions

I’ve been working with some some APIs that have some different patterns for pagination. Which got me to thinking about naming an pagination conventions.

The Problem with ‘up’ and ‘down’ naming

Namely, when describing pagination actions I think it’s probably best to avoid ‘up’ and ‘down’ for naming. These are descriptive words for the ui, not so much of the data.

A -> Z

That is ‘up’ could potentially mean different things in the data depending one what you’re presenting. Let’s say you sort you a list A -> Z by default.  What does down look like in both of these situations. ‘down’ in our minds may imply ‘down’ the alphabet towards the end. But if we can sort to Z -> A the idea of down becomes ambiguous and a bit confusing. For instance if we’re sitting on page M and say down which way does that mean?

Newsted -> Oldest

Let’s consider something that has more chronology. Perhaps a list of recent transactions sorted by date. We could safely presume as you scroll down you retrieve older and older transactions. Describing the each page as down seems reasonable, we’re paging down in time. Specifically the unix epoch timestamp is a number that literally goes down as you go back in time. 1508480500 -> 1508480000.  Makes sense.

Now let’s flip our transaction order to be Oldest first. Now we go 1508480000 -> 1508480500 when paginating down.  Paging down make the number go up. That can get confusing.

Scroll down -> Ticker

To emphasis the opinion of up and down being a UI concern and description. Let’s try one last scenario.

Let’s say we a have a simple twitter feed where we render out messages. Let’s say it’s your typical feed that scrolls down along the page. Paging down make sense here.

But let’s say we introduce stock ticker-styled feed, well now down doesn’t make as much sense. right means down.

Punchline: next and previous

Paginate via a term that is more generic like next and previous seems much cleaner regardless of the UI rendering style.

  • They don’t describe the UI directly.
  • They don’t per-say describe the direction of sorting.
  • Describe the data intent of getting the next chunk.
  • They are ambiguous enough that next don’t imply direction but rather intent.

Pagination is hard

Pagination naming is hard, but good design is amazing. These are just some of my observation and thoughts after working with different apps and APIs. Who knows, maybe there is something better!

ownCloud – a self hosted alternative to DropBox and Google Drive

I’ve used both DropBox an Google Drive for a while. They are wonderful. I’m going to talk for a moment about free self-hosted alternative that I’ve grown fond of.

Cutting to the chase: ownCloud

Features Overview

  • Nice iOS app.
  • Mac & Windows clients are better than Dropbox
  • Support for multiple sync locations and selective sync
  • Public link sharing with optional password or expiration.
  • Server requires just PHP


Sharing works very similar to dropbox. The expiration date & password options are quite nice for limiting who has access and for how long.

Selective Sync

Like Dropbox it supports selective sync.

Bandwidth Limiting

Great for control if you’re syncing large files. The Automatic setting is quite handy

Immutable.js .get() vs. .getIn()

At Sprout Social in some areas of our frontend app we use Immutable.js for our Redux store.

Standardizing Selector Styles.

When selecting state out of our store we’ve written a collection of selectors to consolidate selectors logic. We’ve always write these selectors in array notation to keep styles consistent.

messageStore.getIn([id, 'author', 'screenname']);

With all selectors written in array notation, for Immutable.js we use .getIn() by default — regardless if the path is only one key deep. It’s very convenient. Keeps our selectors looking consistent in shape.


Immutable.js .get() vs. .getIn()

However it is always faster to do a .get() instead of a .getIn() .  For  .getIn() Immutable.js has to iterate through an array path and check the result for each key path along the way. This therefore makes .getIn() expensive and .get() ultimately cheaper.

Abstract .getIn()

So if we wish to keep all selectors a consistent array path style, but take advantage of the speed of.get() whenever possible we could make a get abstraction. The first thing to do is to create an abstraction for Immutable .getIn() — something like this:

Add .get() to the abstraction.

How could we get this handy abstraction to take advantage of .get() whenever possible?
We could peak into the arrayPath , if there is only one value, use plain old .get(). Seems simple enough.

But is it performant?

Array length checking is cheap. With a quick little JSPerf test we can see immediately takins the time to check if we should use  .get() is more than twice as fast than just always using .getIn().

In the end

In the end, this is a micro optimization. However, we saw ~50ms to ~150ms speedups for every actions in the app. It really depends on the how often your selectors run. We have a large number of selectors that fire quite a bit. For such a small change, we’ll gladly take any performance boost over 100ms.

Don’t worry about the abstraction, just remember to prefer.get() over .getIn() whenever possible.

Pro tip: Same goes for .set() / .setIn() and .update() / .updateIn(), etc.

Why I left Windows behind.

Ever since my youth I was Windows fanboy and a Mac hater. I swore to never ever become like those “Mac fanboys“, I scoffed even at the idea…

Alas – My newly found pains with Windows:

1. Background services are priority over focused application

I have a theory that Windows prioritizes Services over the focused application. It is very rare that I see an app on my Mac ‘hang’ or get slow. Hanging apps just sometimes happen on Windows and you sit and wait. This may be why clicking things sometimes feels slightly slow.

2. Slow to open an Application

If I were to race my Mac and Windows opening identical applications, my money would be on my Mac. Can’t say why, but clicking things just happen faster on the mac.

2. Latency between click and response

On a Mac clicking something seems to happen ‘now’ as oppose to in a moment on Windows. The time difference is probably only a handful of milliseconds. Perhaps Windows just likes to animate transitions bit more, but snappiness certainly feels better.

3. Heavy OS

Windows seems to like to make itself visible via animations, sounds, alerts, task bar notifications. Sometimes I just want to focus, but Windows has something it thinks is important for me now. I can’t help but feel that Windows has many moving parts that aren’t per-se coordinated.

5. Stability over time

With age, a Windows machine get’s bogged down by … something. Clutter of background services, taskbar apps, updaters, or something. But even cleaning these up and defragging only seems to go so far. Wiping the and reloading seems to be the only surefire way to make a Windows machine truly fast again. On my Mac, I swear I just have to reboot it (because it’s probably been  month).

6. Frequent reboots required

Speaking of reboots. I’ve had my Mac hit 100+ days of uptime with hardly any issues. This is completely unheard of in the Windows universe. Having an uptime of 7 days, is pretty good for a Windows machine (I have managed 60 +days, but it’s pretty rough by then). With a Windows machine the default it to ‘shut it down’. They just weren’t built for longevity. You constantly must reboot.

7. Long boot time and resume time

When you do reboot, it time for a coffee break. Reboot a Mac, and you might have time to stand up, stretch your arms. When in the workplace, the reboot sound on a Mac is a mark of ‘shame’. Everyone looks around for who was the one that had to reboot their Mac, *gasp*.

8. Sounds, sounds everywhere

Speaking of sounds. Why must every-little-thing make sounds on a Windows machine. Am I right angry little elephant Windows sound? Turning off Windows sounds is the first thing I do on a new install of Windows. Every once in a while they turn themselves back on when you accidentally set a theme instead of a new wallpaper.

9. Lack of SSH

Not to say you can’t install SSH, but the lack of it is a bit of a bummer I can’t SSH from just any Windows machine. Though I hear this has recently changed maybe.

Well thems my thoughts. With all that said… Ironically I still love and use my Windows machines. I didn’t really leave it behind.

React “stateProps PrecalculationError” and TypeError ‘state’ of undefined

Debugging a React component can be a pain.

There are many causes for “statePropsPrecalculationError”, for debugging see my post on Debugging React statePropsPrecalculationError post.

When you specifically have ” ‘state’ of undefined” the fix is simple:

Recently I ran into “statePropsPrecalculationError” alongside with the the console warning TypeError: Cannot read property ‘state’ of undefined(…)`.

This is super easy to fix, but not immediately obvious. Whenever you use `this.setState()` inside your component, you must define your initial state!

Just add a `getInitialState()` definition!

const MyComponent = React.createClass({
getInitialState() {
return {
isOpen: false
toggleOpen() {
this.setState({isOpen: !this.state.isOpen});
render() {
return (

Hello World!