Is a Pure Javascript Canvas Implementation of Matrix Grid ( Primary Application was to Generate Github Like Random Avatar using minBlock.js or Pixel Pattern)
The post minBlock.js : Javascript Canvas Matrix Grid appeared first on jQuery Rain.
Allows you to detect those nasty ad blockers.
Valid On:
The post FuckAdBlock : JavaScript AdBlock Detector appeared first on jQuery Rain.
Provides signature field as jQuery component, using either a sketch pad or an uploaded signature file.
The post jQuery Signature Field appeared first on jQuery Rain.
Ĉapelo is a jQuery plugin for Esperanto accents. Replace 'x' or 'h' by Esperanto letters with accent, as you type.
I’ve been using React.js for a little while now, both in my 9 to 5 job and for my own projects, and during that time I have started evolving my own set of React.js best practices.
The following guidelines mostly focus on component structure and JSX. However, they are not hard and fast rules, but more of an opinionated set of guidelines I choose to adhere to that make my code more readable, more robust and easily maintainable.
Note: This article does not provide explanations of the React paradigms or idioms mentioned here or used in the examples, that is best left to the excellent documentation provided by the React team.
As with any code, it’s important to have consistency. This of course also applies when structuring your React components. I use the following pattern:
React.createClass({
propTypes: {},
mixins : [],
getInitialState: function() {},
getDefaultProps: function() {},
componentWillMount : function() {},
componentWillReceiveProps: function() {},
componentWillUnmount : function() {},
_parseData : function() {},
_onSelect : function() {},
render : function() {}
})
I like to declare propTypes at the top of my component as they are a useful guide to a components expected usage (see section below for more on this), followed by the mixins because it is handy to initially know exactly what external behaviours the component is using/dependent on.
I choose to split the life-cycle methods into those that occur before an instance of the component is created (e.g. getInitialState, getDefaultProps) and those which occur during the mounting/updating/mounted cycle (e.g. componentWillMount, shouldComponentUpdate). Furthermore, I find that declaring the lifecycle methods in order of execution also makes the component easier to reason about.
I always have my custom methods follow the lifecycle methods and be prefixed with an underscore to make them easier to identify. I’ll usually also group these by utility (parsers, event handlers, etc).
I like the render method to always be last. The render method is a mandatory lifecycle method and it’s almost always the function I need to find first when I open a file. Consequently, it’s pragmatic to have it in a consistent location across all of my components.
In general, my mixins will follow the same conventions as regular components.
I always use propTypes to provide validation for each prop the component will receive. Furthermore, this also provides a self-documenting reference for how the component should be used, and what props it needs to be passed.
propTypes: {
arrayProp: React.PropTypes.array,
boolProp: React.PropTypes.bool,
funcProp: React.PropTypes.func,
numProp: React.PropTypes.number,
objProp: React.PropTypes.object,
stringProp: React.PropTypes.string,
}
Let’s face it, JSX can look pretty ugly at times and is one of the more common reasons developers are put off by React. However, by following a few general guidelines for handling JSX in components, it’s far more readable and not such an eyesore.
No matter how few elements are being returned, I choose to write any JSX which contains nested elements across multiple lines with indentation to enhance readability, i.e:
return (
<div>
<ComponentOne />
<ComponentTwo />
</div>
);
Rather than…
return (<div><ComponentOne /><ComponentTwo /></div>);
Furthermore, while the parenthesis are not technically required with a single line JSX statement, I still use them for the sake of consistency (and because unrestrained elements floating about in my JS makes my left eye twitch uncontrollably).
When I have conditional elements that needs to be returned depending on state, props, or another condition, I declare an empty variable at the top of the render function and only populate it with JSX if the condition is met. When the variable is returned in the render method return statement, it’ll either render the conditional elements, or nothing at all.
var optionalElement;
if (this.props.condition) {
optionalElement = (<div> … </div>);
}
return (
<div>
…
{optionalElement}
…
</div>
);
Where possible, I like to iterate over lists of data in-line in the returned JSX unless its internal logic is sufficiently complex enough to warrant moving outside of the return statement and populating an array for rendering.
return (
<div>
{this.props.list.map(function(data, i) {
return (<Component data={data} key={i} />)
})}
</div>
);
When there are enough attributes on a component that displaying them inline becomes untidy (usually 3 or more), I always display them on multiple lines and indent each one. i.e.
<Component
attribute={...}
anotherAttribute={...}
attributeThree={...}
…
/>
Rather than…
<Component attribute={...} anotherAttribute={...} attributeThree={...} />
These guidelines are by no means authoritative or exhaustive, but I feel they are a good starting point for organising and standardising React components and some of the more common use cases I encounter.
Hopefully these guidelines provide a useful starting point for organising your React components. Be sure to leave a comment if you have a question!
An opinionated guide to React.js best practices and conventions is a post from Web Design Weekly.
Smaller and cheaper, yet more efficient than its predecessors, the new machine incorporated two different beams technologies -- an x-ray and a high-energy electron. The different beams allowed operators to target tumours at different depths without damaging nearby healthy tissue. The Therac-25 was both ambitious and sophisticated -- and for the first time all this hardware was controlled by a software layer. Unfortunately, though AECL's intentions were good, their software design was tragically bad, incorporating a series of horrendous design flaws. Later investigations carefully documented these flaws and they're still chilling to read today. In one instance, during a treatment one machine continuously shut itself down reporting a cryptic 'H-tilt' and 'no dose' error message each time. The operator attempted to deliver the treatment six times before giving up. It was only later that it was determined that the machine had delivered the full dose every time. From its launch in 1982 till its withdrawal in 1986, six patients received ultimately fatal injuries from Therac-25 treatments. It's horrendous to consider that these people were already sick. Today AECL exists not as a company, but as a tragic textbook example to all of us of how poorly-designed and untested software can impact lives. The Therac-25 disaster still informs a lot of the ideas we have on systems design and safety testing today. Even if you're a front-end designer, and don't consider yourself a 'serious engineer', Therac-25 teaches us lessons. While some flaws were caused by poorly coded processes, at least as much damage was caused by inadequate documentation, thoughtless messaging and arcane errors messages. These are areas that everyone -- designers, coders, managers, UX people and testers -- should have contact with. Looking back at those ancient egyptians, it's clear that they learned from their early mistakes and went on to build some of the most breathtaking structures that have ever existed. Software engineering is still a comparatively young field -- let's hope we've already built our Bent Pyramids.Continue reading %When Bad Software Kills%
When you’re developing a business idea it can be tempting to build the product as quickly as possible in order to launch it early. Often, this is a fatal mistake because it can result in building a solution to your problem rather than something the users will value.
Although market research might seem like a boring and daunting task, it is still a vital component of any software development project. I’m going to run you through the basics of conducting user interviews so that you can avoid crashing and burning and understand the power that they have. While there are many ways to get feedback from your users, this article is focused on getting thorough insights through user interviews that will actually give you information that you can use.
Conducting user interviews isn’t just a matter of asking questions and jotting down the answers. For an interview to be effective you’ll have to put effort into your preparation. You’ll need to ensure that your questions cover the following areas:
Who: Identify the demographic your product is targeting and tailor your questions to that group. Ask yourself, “Who is my ideal customer for this offering?”
What: What are the problems you intend to solve? The best way to frame this is to think: “What are the biggest pain points my potential users are experiencing?”
When: As you draft your interview, keep in mind the times users will use your product or service. This is best covered by asking yourself, “is this something essential to a users life, or is it something they’ll only use once in a while.”
Where: To further help with identifying context, you’ll need to consider where the product or service is used. For example, users on a mobile device will have a shorter attention span than those on a desktop device. There are many potential answers to this question, but in general you’ll want to focus on whether the product is for work or recreation and whether the user will be on the go or at their desk.
Why: Understanding the psychology of customers is crucial since it’s difficult to change existing behavior. Dozens of companies offer email, but there are plenty of unique aspects that make them appeal to different audiences. Ask your potential users, “What are the biggest reasons you use product X?”
How: Consider how users commonly perform tasks already. Although you can’t really address this without in-depth analytics such as session tracking and more. Having a handle on this is vital to identifying ways to improve the users experience. This isn’t something you can address by asking specific questions. You just need to observe how users interact with different offerings.
Continue reading %Conducting User Interviews That Will Actually Help You%
