MTN DEW x NBA

DEW and the NBA teamed up again for the 2017 season, and we built them a digital hub to house their official partnership, highlight their athletes and showcase their collaborations.
by via Awwwards - Sites of the day

Web Design & Development Agency.

i-Genesys – An Expert WordPress & CMS Development Team in India

by csreladm via CSSREEL | CSS Website Awards | World best websites | website design awards | CSS Gallery

Looking for Imperative Measures to Secure Your Facebook Account!! Check This Out

Facebook; being a vast platform for the web users to communicate with the known-ones alongside sharing news, images, and videos, has posed a threat to them in terms of the privacy risks. As many of the registered FB users have no idea of how to protect Facebook account security breach; others who...

[ This is a content summary only. Visit our website http://ift.tt/1b4YgHQ for full links, other content, and more! ]

by Guest Author via Digital Information World

Editorial: Is Smartphone Addiction a Problem for Developers?

Is smartphone addiction a good thing for developers?

You know the directive: " make great apps that users love. "

And what's the sign that a user _loves_ your app? They use it _frequently_. Frequent relations with your app are a sign of commitment, and commitment is a sign of love. But how does this scale?

As it turns out, a recent report has found that a third of British children are not able to achieve a good balance between screen time and their other activities. Elsewhere in the world, "smartphone rehab" centres (yes, really) are opening up to offer recovery programs for people whose use of electronic devices is excessive. In other, cruder, words, they are smartphone addicts.

A smartphone dependency might not be as flagrant as you'd think. It's a dependency when it prevents you from adequately engaging in other activities. Consider the simple activity of having a dinner with friends or family. If you see a smartphone placed on top of the dinner table, with attention automatically diverted to it whenever its screen periodically flashes up, then its owner is not fully engaging with the rest of the diners. They are in two places at the same time.

Continue reading %Editorial: Is Smartphone Addiction a Problem for Developers?%

by Ariel Elkin via SitePoint

Java’s While and Do-While Loops in Five Minutes

Table of Contents While Loop Example Do-While Loop Example Summary Comments A while loop is a control flow statement that allows us to run a piece of code multiple times. Like loops in general, a while loop can be used to repeat an action as long as a condition is met. The structure of Java’s […]

Continue reading %Java’s While and Do-While Loops in Five Minutes%

by Indrek Ots via SitePoint

7 Deep Work Tips That Will Dramatically Boost Your Productivity

Being busy is more often than not a trap — an illusory euphemism for poor time management. By doing deep work you'll get rid of distractions, gain more focus, get more things done and, unexpectedly, have more time for other things.

Take Cal Newport, the author of Deep Work: Rules for Focused Success in a Distracted World — in just a few years he earned a PhD from MIT, published 4 books and lots of academic papers, all while leaving the office by 5:30PM and rarely working on weekends. Oh, and he's also a professor at Georgetown University, married, and a father of two.

In a more familiar example, I'm a musician, software developer, entrepreneur, and — as of recently — a contributor to online publications (and I'm sure I'm not a multidisciplinary exception among SitePoint readers). I love pursuing all of my goals while learning something new (like a language or a dance), and exercising. I’ve found that I’ve never made more productive use of my time than since I adopted deep work practices.

What is Deep Work Anyway?

Cal, who coined the term, puts it this way:

Deep Work: Professional activities performed in a state of distraction-free concentration that push your cognitive capabilities to their limit. These efforts create new value, improve your skills, and are hard to replicate.

Cal also defines the counter-side of deep work — shallow work:

Shallow work: Non-cognitively demanding, logistical-style tasks, often performed while distracted. These efforts tend to not create new value in the world and are easy to replicate.

While staying focused and doing deep work, you'll find that you multiply your output by 2X, 4X, or even more, every day or week. You'll also feel happier and more accomplished.

Whether you are figuring out the business plan for your startup, doing some programming, or writing content, deep work is a valuable, rare and meaningful asset that will enable you to produce more of what actually makes your business, program, or publishing shine. You get all of this while cutting the clutter and freeing more time for other matters.

So let's get to it!

1. Schedule Your Entire Week Ahead

This may seem daunting at first, but you'll get better at it with practice. You'll see that trying to plan the whole week will force you to actually think and define in detail what it is that you need to do. Also, while you put these tasks in your calendar, you'll need to allocate time for them, also forcing you to be realistic.

Doing this is critically important as you don't want to be wandering through every workday, thinking about what you have to do and making decisions all the time — just check your schedule for today, and execute.

Again, it doesn't need to be perfect. You'll get better at it. Since this is a big one, let's expand a little:

Define Tasks the Right Way

Ask yourself: if I get one thing done this day and feel satisfied, what would that be? Yes, that "one thing" is deep work, and you'll be amazingly productive if you can get one of those tasks done every day (just like the Seinfeld Strategy).

Be specific. "Write article" or "program app" won't do it. You'll have to think in terms of actionable sub-tasks. For writing an article, that could be:

1. Write an outline
2. Write the draft
3. Proof-read and edit

For a program, this can vary wildly, but one possible course of action may be:

1. Define scope and pick a component
2. Research and reference documentation
3. Code
4. Test, debug, and refactor
5. Document
6. Repeat

Be small. Small tasks are more actionable and less intimidating than big ones. While "1 hour of workout" is specific enough, you could end up exhausted and discouraged if you're not used to that level of exertion. Two different blocks of "30 minutes of exercise" could be more approachable (besides, it turns out that even just 30 minutes of daily exercise does the trick). While planning your week, go through this mental process: am I intimidated by this? If the answer is yes, try breaking it into smaller, more actionable sub-tasks.

At the Beginning of the Workweek

Brainstorm the current state of your project. Take a moment to think about what you want to accomplish, and try to deconstruct or reverse-engineer the process so that you can see what its components are.

Review "for later" tasks. You might have a mix of deep and shallow tasks that you’ve been leaving for later. Review them all and see if they fit somewhere in the week.

Leave some room. I normally schedule about 75% of my work week. This makes it possible for me to move things around and handle unexpected events.

You could schedule every minute, and that would be incredibly productive if you're good at it. For most, this isn’t realistic — go easy on the scheduling at first.

At the End of the Workweek

Ask yourself (and be sincere): am I labeling shallow work as deep just to feel more accomplished?

Evaluate. Did it go well? Did you over-estimate or under-estimate time assignments? Keep all of this in mind for next week.

Shut down. You're done. Close all of your browser tabs, apps, and everything work-related. See you next week.

2. Don't Multitask

Multi-tasking is a myth. As I mentioned in one of my articles, changing from one task to another not only has a cost in time, but more importantly, it comes at a very high cognitive expense. That is, it makes you less productive because you let your limited focus and mental power drain as you switch from one task to another. See these articles for more info about this:

• The High Cost of Multitasking: 40% of Productivity Lost by Task Switching
• The True Cost Of Multi-Tasking

Do one thing, and one thing only. Don't attempt to write a report while talking to your peers, or code PHP routines while checking the news. It'll easily take you double the time.

In fact, unless it's your actual job, don't surf the web. This has been happening to me a lot — I'm coding something and some random thought crosses my mind, and I just take a minute to check it on the Internet. Or I take a little break and go check the news for five minutes... don't do it.

One day I was working in a tiny room with no TV, no phone (more on this later), and no Internet. Since I had my computer I decided to focus on tasks I didn't need the Internet for, and I had my most productive day in years.

I hear what you're saying — "if I don't check this right now, I'll forget about it!" Fair enough, make a "for later" note on a piece of paper and put your focus back on what you were doing.

3. Ritualize

The more you can go on auto-pilot for the mundane tasks (cooking, eating, hygiene, relaxing, choosing what to do next), the more focus you'll be able to maintain.

Something you can use the Internet for: search for "morning rituals", read a couple of articles to see if one routine makes sense to you. Put it in practice and you'll see how it pays off after a week or so.

Extra tip: don't do email first thing in the morning. Your brain is at its best after a coffee and a shower, and you want to save this very valuable state for things that actually require this capacity. With some exceptions, replying to email isn't the most mentally demanding task, so leave it for later.

4. Take Breaks from Focus, Not from Distractions

With YouTube, instant notifications, podcasts, and more, we live in a distracted world. If you want to gain more focus to get more done, there will have to be a change of paradigm in your life. You’ll need to make deep work the most important part of your activities, with breaks scheduled around it rather than through it.

Continue reading %7 Deep Work Tips That Will Dramatically Boost Your Productivity%

by Lucero del Alba via SitePoint

How to Organize a Large React Application and Make It Scale

This article is by guest author Jack Franklin. SitePoint guest posts aim to bring you engaging content from prominent writers and speakers of the Web community

In this article, I'll discuss the approach I take when building and structuring large React applications. One of the best features of React is how it gets out of your way and is anything but descriptive when it comes to file structure. Therefore you'll find a lot of questions on StackOverflow and similar asking how to structure applications. This is a very opinionated topic, and there's no one right way. In this article, I'll talk you through the decisions I make when building React applications: picking tools, structuring files, and breaking components up into smaller pieces.

Build Tools and Linting

It will be no surprise to some of you that I'm a huge fan of Webpack for building my projects. Whilst it is a complicated tool, the great work put by the team into version 2 and the new documentation site make it much easier. Once you get into Webpack and have the concepts in your head you really have incredible power to harness. I use Babel to compile my code, including React-specific transforms like JSX, and the webpack-dev-server to serve my site locally. I've not personally found that hot reloading gives me that much benefit, so I'm more than happy with webpack-dev-server and its automatic refreshing of the page.

I also use the ES2015 module syntax (which is transpiled through Babel) to import and export dependencies. This syntax has been around for a while now and although Webpack can support CommonJS (aka, Node style imports), it makes sense to me to start using the latest and greatest. Additionally, Webpack can remove dead code from bundles using ES2015 modules which, whilst not perfect, is a very handy feature to have, and one that will become more beneficial as the community moves towards publishing code to npm in ES2015.

Configure Webpack's modules resolution to avoid nested imports

One thing that can be frustrating when working on large projects with a nested file structure is figuring out the relative paths between files. You'll find that you end up with a lot of code that looks like this:

import foo from './foo'
import bar from '../../../bar'
import baz from '../../lib/baz'

When you're building your app with Webpack you can tell Webpack to always look in a specific directory for a file if it can't find it, which lets you define a base folder that all your imports can become relative to. I always put my code in a src directory. I can tell Webpack to always look in that directory. This is also where you need to tell Webpack about any other file extensions that you might be using, such as .jsx:

// inside Webpack config object
{
  resolve: {
    modules: ['node_modules', 'src'],
    extensions: ['.js', '.jsx'],
  }
}

The default value for resolve.modules is ['node_modules'], so you have to add it too else Webpack won't be able to import files that you've installed with npm or yarn.

Once you've done that you can always import files relative to the src directory:

import foo from './foo'
import bar from 'app/bar' // => src/app/bar
import baz from 'an/example/import' // => src/an/example/import

Whilst this does tie your application code to Webpack, I think it's a worthwhile trade-off because it makes your code much easier to follow and imports much easier to add, so this is a step I'll take with all new projects.

Folder Structure

There is no one correct folder structure for all React applications - as with the rest of this article, you should alter it for your preferences - but the following is what's worked well for me.

Code lives in src

To keep things organized I'll place all application code in a folder called src. This contains only code that ends up in your final bundle, and nothing more. This is useful because you can tell Babel (or any other tool that acts on your app code) to just look in one directory and make sure that it doesn't process any code it doesn't need to. Other code, such as Webpack config files, lives in a suitably named folder. For example, my top level folder structure often contains:

- src => app code here
- webpack => webpack configs
- scripts => any build scripts
- tests => any test specific code (API mocks, etc)

Typically the only files that will be at the top level are index.html, package.json, and any dotfiles, such as .babelrc. Some prefer to include Babel configuration in package.json, but I find those files can get large on bigger projects with many dependencies, so I like to use .eslintrc, .babelrc, and so on.

By keeping your app code in src, you can also use the resolve.modules trick I mentioned earlier which simplifies all imports.

React Components

Once you've got a src folder, the tricky bit is deciding how to structure your components. In the past, I'd put all components in one large folder, such as src/components, but I've found that on larger projects this gets overwhelming very quickly.

A common trend is to have folders for "smart" and "dumb" components (also known as container and presentational components), but personally I've never found explicit folders work for me. Whilst I do have components that loosely categorize into "smart" and "dumb" (I'll talk more on that below), I don't have specific folders for each of them.

We've grouped components based on the areas of the application that they are used, along with a core folder for common components that are used throughout (buttons, headers, footers - components that are generic and very reusable). The rest of the folders map to a specific area of the application. For example, we have a folder called cart that contains all components relating to the shopping cart view, and a folder called listings that contains code for listing things users can buy on a page.

Categorizing into folders also means you can avoid prefixing components with the area of the app that they are used for. As an example, if we had a component that renders the user's cart total cost, rather than call it CartTotal I might prefer to use Total because I'm importing it from the cart folder:

import Total from 'src/cart/total'
// vs
import CartTotal from 'src/cart/cart-total'

Continue reading %How to Organize a Large React Application and Make It Scale%

by Jack Franklin via SitePoint