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 Preset.zip
Ma na celu zrównoważenie realizmu skoncentrowanego na zewnątrz, a oświetlenie wnętrza wystarczy, aby nadać kontekst na scenie.
Presety-> Reveal User Preset FilesThis is my first easyHDR preset available to download. Feel free to share and link back. Preset bundles will be coming soon.
Interior to Exterior 1 – jStassen Preset.zip
The preset focuses on realism on the exterior, while illuminating the interior just enough to give context for the scene.
Presets-> Reveal User Preset Files
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.
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.
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?
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.
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.
next and previousPaginate via a term that is more generic like next and previous seems much cleaner regardless of the UI rendering style.
next chunk.next don’t imply direction but rather intent.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!
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.
2019 UPDATE: I now recommend NextCloud. It’s the same, just a different name.
Sharing works very similar to dropbox. The expiration date & password options are quite nice for limiting who has access and for how long.
Like Dropbox it supports selective sync.
Great for control if you’re syncing large files. The Automatic setting is quite handy
At Sprout Social in some areas of our frontend app we use Immutable.js for our Redux store.
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.
messageStore.getIn([id]);
.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.
.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:
.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.
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().
https://jsperf.com/immutable-get-getin-path-check/1
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.
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:
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.
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.
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.
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.
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).
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.
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*.
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.
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.
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 (
);
}
});
Instagram is unique when it comes to the rules for usernames and hashtags. Here is a regex to capture and validating them with the JavaScript regex engine.
(?:@)([A-Za-z0-9_](?:(?:[A-Za-z0-9_]|(?:\.(?!\.))){0,28}(?:[A-Za-z0-9_]))?)
For hashtags use the same regex, it’s the same rules, just replace the @ for a #.
(?:#)([A-Za-z0-9_](?:(?:[A-Za-z0-9_]|(?:\.(?!\.))){0,28}(?:[A-Za-z0-9_]))?)
You can try it out over on Debuggex. Here is a an example implemented in JavaScript.
Here are a few mixins I’ve created for LoDash.js I’ve found handy.
_.getDeep
/**
* Safely retrieves the value of a deeply nested object value
* @param {object} O The Object to be searched
* @param {string} str Dot notation string of the address of the attribute to be retrieved
* @return {mixed} Value of nested item or undefined
* @link http://stackoverflow.com/a/15400575/417822
*/
_.mixin({'getDeep': function(O, str) {
if ( !_.isObject(O) ) return;
var seg= str.split('.');
while(O && seg.length) {
O = O[seg.shift()];
}
return O;
}});
/**
* Tests if a deep value has a value/exists. Uses _.getDeep to retrieve value.
* @param {object} O The Object to be tested
* @param {string} str Dot notation string of the address of the attributed to be tested
* @return {boolean}
* @todo validate that falesy values 'false' '0' etc come back as true.
*/
_.mixin({'hasDeep': function(O, str) {
return !_.isUndefined( _.getDeep(O, str) );
}});
_.isDefined
Because typing !_.isUndefined() all the time is tiresome. Using _.isDefined is clear and more readable.
/**
* Shorthand for !_.isUndefined
* @param {mixed} e Item to be tested
* @return {boolean}
*/
_.mixin({'isDefined': function(e) {
return !_.isUndefined(e);
}});
/**
* Removes all falsy and undefined values from an object
* @param {object} o Object to be compacted
* @return {object} Compact Object
* @link http://stackoverflow.com/a/14058408/417822
*/
_.mixin({'compactObject': function(o) {
var clone = _.clone(o);
_.each(clone, function(v, k) {
if(!v) delete clone[k];
});
return clone;
}});
_.compactObject
/**
* Toggles an array element
* @param {Array} arr Source Array
* @param {Mixed} val Value to toggle
* @param {Boolean} Optional: Boolean to determine whether to add or remove
* @return {Array} Result
*/
_.mixin({'arrayToggle': function(arr, val, state) {
if ( _.indexOf(arr,val)==-1 || state)
return _.union(arr,[val]);
else
return _.without(arr,val);
}});
In my understanding there are different types of data. Each is unique in purpose, mutability, and scope. Clearly identifying the role of an attribute and grouping it with related ones creates a cleaner interface to work with.
The raw data that is persisted to the server.
This data should be treated as if immutable, unless planning to persist a change of one of the values to the database. This is the once source of ‘truth’ that is trustworthy. If it is reformatted, or changed it looses its trustworthiness.
user: {
firstName: 'Phil',
lastName: 'McCool',
username: 'pmccool'
}Take in Raw Data, and reformat it for later use.
More often than not these are a convince to remove the need to repeat logic throughout the app.
If there is an urge to create a value here to describe the model’s content ‘isAdmin’, ‘fullName’, there is a good chance these ought to be part of the data schema to start with.
They can come at a cost of being computed but not always needed everywhere throughout the app. Alternately getter functions could be used to allow a more ‘on-demand’ approach (add result caching and get the both of both worlds).
computed: {
fullName: 'Phil McCool',
shortName: 'Phil M.',
numberVowels: 3
}Describing the state status, of either the data or of the component/view.
State data describes progress or what things are doing currently – [changing, updating, modified]. While these are similar to configuration items, they mutable are more closely tied to the model data describing what is happening to it. If their were multiple components/views that display the same model, they may all want to know the current state of the data. It’s meta data to the data.
These values should update frequently.
state: {
isLoading: false,
isModified: true,
page: 4
}How something should be displayed or behave.
These ought be on the component/view that is rendering the item. It describes the preferences of how something should behave or be displayed. Think of them as options, ways to deviate from the norm, an API for this component/view.
A component/view should have a set of defaults for these values to fall back upon.
Config attributes can make it tempting to overload abstraction. Draw a line of making a new component/view when the core functionality has config options that cause different logic paths.
config: {
size: 'large',
template: 'card',
color: 'blue'
}
It can be very tempting to merge or stuff configuration and state data right into the model data. It’s convenient, but lazy. It taints the raw data. If put an ‘isLoading’: true value into our data model then persist it to the server, we ought to feel like we did something wrong.
Ideally we would be able to group data in our actual data structures, but at minimum, we can always just keep in mind the role of an attribute and group mentally.