Front-End Challenge Accepted: CSS 3D Cube


  

Do you like challenges? Are you willing to take on a task that you’ve never come across before, and do it under a deadline? What if, in carrying out the task, you encounter a problem that appears unsolvable? I want to share my experience of using CSS 3D effects for the first time in a real project and to inspire you to take on challenges.

Front-End Challenge Accepted: CSS 3D Cube

It was an ordinary day when Eugene, a manager at CreativePeople, wrote to me. He sent me a video and explained that he was developing a concept for a new project and was wondering if it was possible for me to develop something like what was in the video.

The post Front-End Challenge Accepted: CSS 3D Cube appeared first on Smashing Magazine.


Source: Smashing Magazine

Why You Should Make the Worst Parts of Web Development Even Worse

A dilapidated room

Being a developer can be a nightmare…

… if you’re in the wrong environment. For many developers, it’s a constant source of stress, frustration and anxiety. As a web developer, you love writing code.

[author_more]

The other headaches? They’re things you can do without.

If you’re experienced, you’ve dealt with the same headaches over and over. At times it feels as if someone’s playing a cruel joke on you or that everyone you work with is crazy. And the worst part?

These headaches aren’t going away.

When they’re ignored, these mistakes typically leave developers feeling miserable, jaded and downright unhappy.

That doesn’t have to be you.

Savvy Developers Use These Headaches to Their Advantage

They turn these everyday disasters into opportunities they can use. Average developers complain about these headaches, hoping to avoid the inevitable. All-stars use these everyday disasters to make themselves and others better.

What’s their secret?

It’s a simple secret most aren’t willing to accept. It sounds obvious to most people when they hear it, when in reality, it’s anything but. Here’s the secret.

Do what others won’t.

That’s it.

Do this, and your value as a developer skyrockets. Master it, and you become irreplaceable.

Experience is Great, Vaccination is Priceless

For many developers, these headaches are crippling. Most developers hate dealing with these problems. At a certain point they begin to feel trapped. They’ve got a full blown case of learned helplessness. On an emotional level, they’re afraid they’ll be blamed if something goes wrong. And to a certain extent they’re right.

But avoiding the problem isn’t the answer.

Facing the problem gives you freedom and control. When you face the problem the despair, anger and fear loses its sting. As great as experience is, it can’t hold a candle to vaccination.

Dominate these problems and you vaccinate yourself, emotionally and psychologically, against them.

Which problems are we talking about?

Headache #1: Fixing Someone Else’s Broken Code

You’ve just been hired at a new job. Your first to-do item? Fixing a poorly made application the previous developer left behind. Which either has no documentation (he didn’t believe in that) or too much documentation.

But the complications don’t end there.

Developers, like writers, are unique. They all have their own style, their own way of doing things. The code you happen to be working with is long, complicated and filled with bugs. Tossing the whole thing out and starting over would be best.

Only you can’t.

Because this code is live and in use.

Make it worse:

So you put a stop gap in place. You make the temporary fix you need to keep things going. But you don’t stop there.

You take the time to map things out. What does the undocumented code do? Which libraries are being used where? Where are the conflicts? What are the dependencies? Learn absolutely everything you can about the poorly made system you’re fixing.

It’s tedious and miserable, at first. But it’s something the vast majority of developers do their best to avoid. Here’s why you should do it.

Thorough understanding gives you the ability to create change that sticks. You’ll know the system better than anyone else on your team. That makes you indispensable.

Do this well and you’re able to survive mass layoffs, company politics, and disasters. They can’t afford to lose you, you’re one of the few developers that knows things inside and out.

Headache #2: Fixed One Bug, Created Ten

After three hours of searching, you’ve finally found it. The fix is easy enough, so you push the update out. Only now, instead of that one original bug, there are ten.

Maybe the library you’re using has lots of bugs. Maybe your update created a conflict with something else. Or maybe the bugs are unknown — as in you’ll never find the problem. If you’re lucky these bugs will magically go away on their own.

Make it worse:

First things first: get up and walk away. There may be a lot of pressure to find a solution, but your conscious mind needs a break. So you do the smart thing and you walk away.

Doing this moves the problem to your subconscious mind where you’ll continue to work on it. Had a solution pop into your head while you were in the shower? Come up with a brilliant idea while you’re falling asleep? That’s your subconscious at work.

But there’s another reason you should walk away.

Fear, stress and anxiety affects your mind negatively. A research study by the NIMH showed that cognition, memory, decision making, even spatial navigation were impaired by negative emotion.

Deal with your negative emotions first, then come back.

Start asking questions, focusing your attention on isolating the problems. Revert to a previous revision.

  • Are the bugs still there?
  • Are they the same bugs or slightly different ones?
  • Were any of the bugs resolved when I reverted to a previous version?
  • When are these bugs present?
  • Are these bugs superficial, non-critical, critical or showstoppers?

Asking lots of questions trains your mind to search for answers. The answer tells you something about the problem. Keep asking questions to find the problems faster.

Headache #3: This Thing I Need, It Is the Problem

You’ve been assigned to a new project — integrating a client’s website with a new provider’s API. They provide you with the keys and credentials you need. Seems like everything’s good.

Until you run some tests.

Everything looks right but you can’t get things to work. You reach out to your point of contact and you ask for some help. They can’t make heads or tails of it either. Your API calls aren’t working.

You’re already behind schedule. At this rate, you won’t hit the deadline if things aren’t resolved in the next day or so. But no one seems to know what the problem is.

Make it worse:

Here’s a habit we used in our agency. We made it a habit to find an alternative provider, solution or option. If a client wanted A, we gave them A but we had B ready to go, just in case.

  • If clients want Netsuite, you’d have Tracmor and TradeGecko on the backburner, ready if something went wrong.
  • If they’re using a particular library, we’d find (or in some cases, create) a new library. This is tricky to do and depends on your ability to spot serious red flags ahead of time.
  • If they wanted things developed in Java, we’d have a secondary language with code samples, libraries, API documentation, etc. ready, just in case.

In the beginning, it feels tedious. If you’re on a development team you already have a lot to do. It feels like you’re running from one fire to the next, doing all you can to keep up.

Know what I mean?

We felt the same way. But here’s what we found. Doing this extra work forced us to be efficient. We were prepared for the unexpected and our process improved as a result.

You’ll quickly get a sense of who is good at what, and you’ll rely on each other to get things done. You’ll begin to gel as a team and at a certain point, the work is being done — without words.

This doesn’t mean you stop talking. It means your discussions and conversations become more efficient. These kinds of teams dramatically outperform groups that simply work together.

Continue reading %Why You Should Make the Worst Parts of Web Development Even Worse%


Source: Sitepoint

Browser Trends July 2016: Is a Chrome Monoculture Harmless?

May’s Microsoft Misfortune saw IE and Edge plunge further behind the competition. Does June provide a more optimistic outlook in the latest StatCounter browser statistics? Er, no…

Worldwide Desktop & Tablet Browser Statistics, May to June 2016

The following table shows browser usage movements during the past month.

BrowserMayJunechangerelative
Chrome57.07%57.99%+0.92%+1.60%
Firefox14.50%14.14%-0.36%-2.50%
IE118.65%8.18%-0.47%-5.40%
oldIE2.73%2.59%-0.14%-5.10%
Edge2.29%2.55%+0.26%+11.40%
Safari4.32%4.28%-0.04%-0.90%
iPad Safari5.35%5.33%-0.02%-0.40%
Opera1.80%1.68%-0.12%-6.70%
Others3.29%3.26%-0.03%-0.90%

Continue reading %Browser Trends July 2016: Is a Chrome Monoculture Harmless?%


Source: Sitepoint

Horizon: A Scalable Backend Perfect for JavaScript Mobile Apps

Horizon is a scalable backend for cross-platform, JavaScript based mobile apps, especially those needing realtime functionality. It was built by the awesome people at RethinkDB and so uses RethinkDB as the default database. If you’re not familiar with RethinkDB, it’s an open-source database with realtime capabilities.

Horizon exposes a client-side API that allows you to interact with the underlying database. This means you don’t have to write any backend code. All you have to do is spin up a new server, run it and Horizon will take care of the rest. Data is synced between the server and the connected clients in realtime.

In this tutorial you’re going to build a Tic-Tac-Toe app with Ionic and Horizon. I’ll assume that you’re not new to Ionic and Cordova so I’m not going to explain Ionic-specific code in depth. I recommend you go check out the Getting Started Guide on the Ionic Website if you want a bit of background. If you want to follow along, you can clone the app repo on Github. Here’s how the final app will look:

Continue reading %Horizon: A Scalable Backend Perfect for JavaScript Mobile Apps%


Source: Sitepoint

Web Development Reading List #143: The Referrer Header, Third-Party Scripts, And Color Psychology


  

Hey! I don’t have a lot of links for you this week, but I feel that the ones that I selected are particularly useful to read. I learned about how to break Google captchas, the Referrer header, color psychology, and read an amazing new article by Maciej Cegłowski whose articles and talks I value a lot. Enjoy your weekend!

A malfunctioning third-party script

The post Web Development Reading List #143: The Referrer Header, Third-Party Scripts, And Color Psychology appeared first on Smashing Magazine.


Source: Smashing Magazine