venerdì 23 gennaio 2015

15 Resources To Get You Started With jQuery From Scratch

 

In this industry - now more than ever - designers are becoming coders, and coders are becoming designers. The idea of a developer ONLY performing frontend or backend work is quickly becoming a dated concept. jQuery will help to bridge the gap. Javascript is not an unattainable skill. In this article, we'll detail fifteen resources to get you started with jQuery from the absolute beginning. If you've been avoiding this library out of some silly sense of fear, now is the time to dive in. You'll be amazed at how simple it can be.

Becoming a PHP Professional: Practical Teamwork

Last time, we discussed social aspects of teamwork, and how working in a team can both benefit and harm you. There's loads to take into consideration when working with other people, and lots to be gained.

This time, let's talk about practical aspects of teamwork, particularly virtual teams or, in other words, teams with remote members.

Time Zone Difference and Broken Bottleneck in Teamwork

When working in a team with remote members, time zone differences can be a huge hindrance. Take for example SitePoint itself – I write for an audience which is, in a large part, US, SitePoint's HQ is in Australia, and I'm based in Croatia. That's three time zones 6-8 hours apart each, which means a full day can elapse before people answer your emails.

When you have a lot of emailing back and forth, not only among the team members but also among the clients, authors and whoever else, things tend to get messy fast. You need a way to stay in sync with everyone at all times.

Another problem is what I like to call a broken bottleneck syndrome. Usually, when only one person is directing requests to the development team (a filter, team lead or the project owner, for example), that person can become a bottleneck if the requests are coming in too strong or the dev team is too slow or small to implement them. The people feeding that person with instructions then tend to go around him/her, and cause a spillage of (often contradictory) information overflowing the dev team.

Yet another frequently encountered issue is multiple people working on the same piece of code. Bad prioritization and organization, in a nutshell. Sometimes, a developer might even end up in bug-jail (that's when you have so many bugs on your previous work, you're forbidden from building anything new until you get out of this jail mode), and this halts further development, especially if other devs depend on your completion of your part.

These issues can slow down development or even, at times, bring it to a complete halt, and there are several remedies for them. We'll divide them into organic and inorganic solutions.

Organic Solutions

As I mentioned in the previous article, the importance of a capable lead and a capable filter cannot be understated. The capable lead will be able to formulate tasks properly and divide them into smaller units, while the capable filter will make sure requests that don't make sense or just aren't worth implementing never even reach the ears of the developers. A filter's role is absorbing the requests of the rest of the company, and being the only means of communication between the dev team and the non-technical folk. The filter's strength directly influences the time it takes for a broken bottleneck effect to occur.

A capable filter needs your help – you need to refuse orders from unauthorized people. Even if you get approached by the CEO, bring the task to the CTO/project lead/team lead before even considering doing it. Your superiors are usually closer to the person making unreasonable or simply out-of-schedule demands, and can nip it in the bud. Fail to resist once, and you set an unhealthy precedent.

Even if non technical people do somehow breach the barrier, make sure you're tolerant and calm towards them. We all know how utterly frustrating it can be when a marketing person keeps calling a web page a slide, or when a logistics person can't describe an interface in words you'd like them to use and instead compares everything in life to Excel stylesheets, but tolerantly listening and decoding their wishes means you can a) get rid of them faster and b) describe their desires to the lead/filter, so they can approach them, explain things, and maybe formulate a task if it truly is urgent.

An enormous help is making sure there is at least some work hours overlap. Setting up your work time so you can have an overlap of at least 2 working hours with the rest of the team and especially the lead is of utmost importance. An overlap in work hours allows you to catch up in real-time, and lets you perform another incredibly important aspect: video and voice calls. If a picture is worth a thousand words, a call is worth a thousand emails. One call can both help you report on your day, dig deeper into unclear tasks and requests, build a better itinerary, register complaints and it has the added benefit of improving your English.

Inorganic Solutions

Under inorganic solutions, there are several applications and web services I'd like to mention. The list is by no means exhaustive, but I've used most if not all of them at times, and I don't recommend something I don't actually stand behind – rest assured that all these do what they're supposed to do, and do it well.

Trello is one of the main tools we use at SitePoint. It's more non-developer oriented, more appropriate for editors and managers, but its excellent todo-ish card layout and markdown support make all tasks easily describable and clearly visible. If you communicate with non technical personnel on a regular basis or like to throw ideas around with teammembers, Trello is a good choice. There's a free option, so give it a go.

Basecamp is a popular alternative to Trello, and is basically a glorified team-enhanced to-do list. Like Trello, it supports nesting, discussions and file uploads. It's not free, though.

Google Apps can host your entire company's email folio and follow it up with closed-door Google Docs and Google Drive, as well as group messaging, Google Groups, company calendar and much more. Google Apps are an entire suite of applications I wish more companies used. What's more, Google Apps for Business supports Hangouts, so you can communicate via IM with your team, and even send messages to and from your mobile phone. In fact, Hangouts even goes so far as allowing you to join a video call from two locations – for example, if you're getting a video call while you're 5 minutes away from the office, you can answer it and talk on your phone. As soon as you reach your computer, simply hitting "Join this call" will open a stream on the computer as well, and you can hang up on your phone (or leave it on and have multiple camera angles of yourself). It's all extremely fluid, and makes for a truly professional communication environment.

FlySpray is a super simple web based open source bug tracking system that can help you handle the simple bugs in day to day work. In my previous company, we used it as a front – we let the non technical people submit bugs and requests there, and then a filter person would weed out the nonsense and describe the proper bugs into more detail. This made sure we never got an incomplete report, which made reproduction and fixing that much faster.

Github is an online social coding network. It's a hub of open source repositories (or closed source if you pay) where everyone in a team can easily collaborate, without the pain of manually setting up a repo on your own servers. BitBucket is a viable alternative, and offers free private repos, as opposed to Github.

Atlassian, the makers of BitBucket, also have various other excellent team collaboration tools like Confluence and JIRA – both allowing you to work with your team in real time and use a single point of data collection. Jetbrains also offers a good set: TeamCity (free professional edition) for continuous integration and YouTrack (unlimited 60 day trial, or 10 user free pack) for issue, request and bug tracking.

If you do Agile Development (more on that in a future article), the best tools for the money are said to be PivotalTracker and GreenHopper (a JIRA Agile plugin) these days. Both tools have some free plans you can try out, but we'll do a more in-depth analysis soon.

Last but not least, if all you need is a good team based todo list, I can't recommend Wedoist enough – being very similar to Todoist (which I use daily), the interface is streamlined and focused on the tasks at hand. It's everything you've ever seen in all the other Todo apps, but much improved.

If you're the member of a dev team, I recommend a healthy mix of Github and TeamCity, and Trello for discussions. If you're in a managerial position and decide on projects and courses to take, I wholeheartedly recommend Google Apps. If you're in a flexible remote team, use Wedoist and see how it suits you. If you practice SCRUM, add PivotalTracker to the mix.

Conclusion

This article offered some practical solutions for improving teamwork and productivity in a team. In a follow-up article, we'll be covering practical team based tools in greater detail.

 

VIA: SitePoint/PHP

Becoming a PHP Professional: Social aspects of teamwork

After discussing the general guidelines to reaching an Intermediate+ level in PHP development in Part 1 and the importance of others around you in Part 2, this article will focus on social aspects of teamwork and initiative, and will serve as an introduction into a more concrete and practical teamwork based article coming soon.

It's important to note that when I say teamwork, I don't only mean teams while working for a larger entity – a corporation or company in which you're a minor sub-group. A team is also a group of freelancers working together on a project – either close by, or remotely. Whenever you work with someone in any capacity whatsoever – that's a team. A loose team, but a team nonetheless.

Know your role

It's no secret we developers tend to be bigheaded sometimes – in all areas of life, not just coding – especially when being given (or succeeding in) a task of mid to high level importance. It gives us a sense of false security and we tend to forget that we don't, in fact, know everything.

It's only natural, then, that we feel like we're more important than our designated team role lets on. In times like these, it's important to step back, cool down, and look at things from a different perspective. Put yourself into the shoes of other team members and look at yourself from afar. Realize why you're there and what you're supposed to do, and respect the fact that every member of the team has a specific purpose.

You might be better at front end engineering than the team member they hired for the position, but if you're there doing PHP, consider the net gain of proclaiming such a fact publicly. While the front end dev might be mediocre, you were mediocre at one point too – without the experience of working on different projects, you never would have outgrown the mediocrity. Furthermore, what can be gained by replacing said member? If the member is actually bad at his job and does harm to the project, by all means, this should be brought to the team lead's attention. But if he's just "ok", replacing him could actually have a negative impact on the progress of the work, causing unnecessary delays.

Not stating the fact publicly could have even worse implications – it could sow dissent in the ranks, making the other team members take either a defensive stance against you due to your underhandedness, or taking an aggressive stance towards the person you have a problem with which, again, isn't healthy for the team as a whole. The healthiest solution is, by far, approaching the person in a friendly manner, giving advice, and discussing everything openly.

But what if it's the project lead who is so bad he does harm to the project? Well…

Respect superiors – to a degree

Superiors are like elders – they're to be respected, but to a certain degree. Of course I'll listen to what my grandma has to say. She's been around for much longer, she's bound to have at least passively absorbed some wisdom she can impart. But if she starts trying to brainwash me with old habits and attitudes, her close-mindedness will render me non receptive to her words.

It's the same with superiors in a team. Respect their decisions, accept their advice. If someone is higher up on the corporate or team ladder than you are, there's a reason for that – and more often than not it actually is skill and experience, contrary to many people's beliefs. Keep in mind that everyone you ever meet knows something you don't, and be receptive of their opinions, even if you disagree with them – there's often more to be learned from disagreement than agreement. A light difference in opinion can be researched and discussed productively, and someone is guaranteed to come out of the situation with knowledge they didn't have before.

Admittedly, there's a dark side, too. There are times when the only reason someone is superior to you is because they're better connected to the project owner. These circumstances usually aren't obvious at first, but in time, they always become fully transparent. Speaking from experience, the symptoms of incompetence can be anything from refusing to move away from PHP 5.2 in 2012 on a brand new project, to contradicting oneself in tasks just to cover up for previous errors in judgement. It won't be long before their bad calls start to harm the project – soon enough, everything that goes well will mysteriously be attributed to them, and everything that goes wrong will require an in-team scapegoat. This type of person is usually excellent at diverting attention and misdirection in order to keep their position as long as possible, because their high rank usually involves bonuses or other privileges – and if the project falls through eventually, it's just one black spot on their CV, but a thick bank account and lots of influence.

When you detect such an environment, there's no rational way to repair it. Going to the project owner usually makes no sense, because they're either too attached to the person (blood relatives, personal friends) or completely fooled – and the latter is usually worse, because the longer the situation lasts, the less willing the CEO or project owner becomes to admit that they've been duped all that time. Projects like that usually crash and burn after a prolonged state of plateau, so…

Don't be afraid to leave

When you realize this might be the case, it's important not to be afraid to leave. The temporary security the job offers at that stage is just that – temporary. Remember, the project will crash and burn, undoubtedly, it's just a matter of time. The situation is unfixable without a change in management, and changes in management don't tend to happen all that often.

You should always be on the lookout for better offers, but when you find yourself in a downhill situation, start actively looking. Go to interviews, apply for projects, just don't be passive about it. It's hard when you have dependents, and risking the loss of a regular paycheck can be very taxing on one's psyche, but trust me when I say that sticking around in such an environment can be even more taxing, not only for you, but those around you as well.

I write from personal experience. I was forced to leave my job due to these exact conditions, but instead of settling for a similar pay with another IT company, I opted to go freelance. Going freelance allowed me to pick my own projects and clients, to choose technologies I'm comfortable with or interested in, and to learn more than I would ever have learned having remained stuck in the faulty team.

Conclusion

While this article had little to do directly with PHP, it is the opinion and experience of someone specialized in PHP. It's also a precursor to the next article on teamwork which will cover remote work, pair programming, dealing with time zone differences, types of teamwork, and more.

What I'd like you to take away from this part is – don't be a slave of circumstance. Be courteous, professional and honest, but don't be afraid to leave a poisonous environment – it harms you, the people who love and support you, and finally, the project you're working on. I left and, personally, I have yet to look back with anything but relief.

Do you have any team based horror stories? Success stories perhaps? Attitudes differing from those exposed in this article? Let me know in the comments below.

 

VIA: SitePoint/PHP

Becoming a PHP Professional: The Importance of Others

This article is a partial followup to the previous article about becoming a PHP Professional, but with a focus on mentorship. While this is, in fact, just a personal impression I've cultivated over the years in the industry, I encourage everyone to read it and see how much they agree or disagree with the notions I present.

The buddy system

In "The Missing Link", I briefly touched on finding a mentor, companion or friend to work with. I'd like to expand on that point slightly.

When you work on improving your skills on your own, you'll often find yourself stuck. In fact, the experts frequently find themselves stuck more often than newbies, but it's the speed and skill with which they "unstick" themselves that makes them stand out in the cold, snowy field of identically unimpressive snowflakes.

This intense digestion of a problem is, with beginners, additionally slowed down by the fact that they neither know where to look for solutions, nor in which direction to steer their thoughts. A solo newbie stuck on a never before seen problem often ends up in a limbo not unlike the Stanley Parable, spinning round and round through dull, yet strangely interesting hallways until ending up at the beginning again.

When you have an equally interested and motivated companion beside you – be it your partner, a mentor, a boss, a team member, a cat you simply shout theories at, or just an innocent bystander who can think logically and is unable to run away as you posit your question – the problem is, often quite literally, half as difficult to solve.

Even an imaginary buddy helps at first, if you have no one real nearby. On countless occasions I've found myself explaining a problem to my boss only to come to the solution half way through, simply because I listed the alternatives and roadbumps out loud.

So, if two heads halve the problem's difficulty (or, rather, the time it takes to solve the problem at its original difficulty), ten heads solve it ten times faster, no? Not always.

Teams

There's a saying that when you feel like you're the smartest person in a room, you're in the wrong room. This applies to all areas in life, but to disciplines of logic and science especially so. Teamwork doesn't necessarily mean you'll solve an issue faster if you're the only driving force of the team.

It's important to get to know each member of the team well, and get along with everyone – maybe not necessarily on a personal level (though it helps) as much as on a professional level. Being on the same wavelength and frequency as your colleagues makes sure the brainwaves intensify, rather than cancel each other out. A good atmosphere can have a compound effect on problem solving.

If you find yourself in a team, find someone you admire, someone you'd like to be better than. Don't feel rotten because you want to "beat" them – feel inspired. Make them your drive. Learn from them, absorb everything around you, talk to them. Never be ashamed to ask for advice, and never be afraid to ask for help if the person isn't deep in a working cycle.

If the team or some particular member is hostile, if the atmosphere is lacking, if the leader figure knows less than you do and still refuses your suggestions without discussing them with others, you should request a transfer. Such a negative environment not only prevents progress, it reverses it – you'll find yourself slumped behind your desk and reading Reddit more often than expecting a solution to a problem from yourself, simply because you'll feel it isn't worth it. Move away from poison.

Mentoring and being mentored

If you don't have a team, or your team situation is unfixable (nothing is, come on!), it's time to jump even further out of the comfort zone and look for an actual mentor. If you're an introvert and aren't comfortable with talking to strangers, as we developers tend to be, try out the SitePoint Forums, or a quasi-anonymous service like Wizpert first, go through an issue or two and see how it goes. Join us on Google+ to discuss some posts, comment, give feedback or just chat us up for the heck of it.

If you feel like you need more specific mentoring, however, there's an excellent website dedicated to just that: PhpMentoring. The way it works is, mentors willing to share some of their knowledge and apprentices willing to receive it all sign up on the listings page. Basic information is given, like name, location and current skill level. The mentors also specify their areas of expertise, while apprentices single out the aspects they would like to improve or master. In a way, it's not unlike a dating site – you look over some candidates, and if someone is teaching something you want to learn and lives in a relatively similar time zone, or if someone is willing to learn something you're teaching, you get in touch with the person and handle the rest via face-to-face or online communication.

You might be wondering what's in it for the mentors. The mentors get contacts, networking, and the good feeling of helping someone grow. Some of them even use this opportunity to directly train someone for employment in their company, or to include them on a project doing tasks they've outgrown. Apprentices getting paid for the work they're doing for/with the mentors is not an uncommon situation.

Once the mentorship link begins, it's up to the participants to be punctual in their arranged meetings and to regularly communicate and give feedback to each other. It's also important to note that someone being an apprentice doesn't necessarily mean newbie. Someone might be an expert in object oriented programming, but unskilled in test driven development. As such, that person might be both a mentor candidate for OOP, and an apprentice candidate for TDD.

Don't underestimate your peers, or their general significance. If you have no one to look up to, you cannot progress. Without a way to visualize your goals, you cannot strive to achieve them.

Ego inflation and deflation

One of the most dangerous things that can happen to you as a beginning to intermediate developer is ego inflation. It happens for all sorts of reasons, but is usually triggered by a combination of some that follow:

  • a successful completion of a complex tutorial
  • too kind feedback from a dishonest or sub-par mentor
  • getting asked questions by people new on the team
  • successfully selling a website
  • getting contacted to write a book by a charlatan publisher who uses keyword search to track down candidates
  • getting contacted by recruiters
  • and more…

When ego inflation occurs, the developer tends to enter a state in which he is absolutely convinced he is right and his way is best. He believes it so zealously, he even convinces his coworkers and clients to adopt his way of thinking. That's when things get dangerous, projects get delayed, and clients get disappointed. Ego inflation is harmful to others around you, because it tends to steer people blindly onto the wrong path, and push colleagues away due to arrogance. Sometimes a more assertive member of the team will put a stop to this, but more often than not, the ego inflated developer will either fizzle out or crash land into deflation either by force or on his own.

Ego deflation is utter discouragement to continue with the work – be it actual work, or self-upgrading. It, too, happens for various reasons, some of which are that the inflated egoist realizes he's wrong and/or is put in his place by a more experienced and assertive developer, or simply after soloing too much for too long and burning out. A deflation can last several months, and during that time an incredible amount of progress is lost.

Others around you – either digitally or in real life – can protect you from both inflation and deflation – a good mentor or colleague will tell you when you're steering wrong, and they'll motivate you when you're in a slump. They'll help you avoid the multi-month cooldown periods and the post-burnout lack of interest that eventually occurs.

Conclusion

Don't forget, like Bill Nye, the Science Guy said:

Everyone you will ever meet knows something you don't

Never underestimate the power of others. Go to conferences and meetups, attend hackathons even if you don't code anything, follow good content, subscribe to newsletters, join forums, talk to people and above all – never underestimate anyone. You can earn valuable nuggets of knowledge by digging around in other people's brains – be they newbie or pro.

If you liked this article, please share it with your friends and colleagues and join the discussion in the comments below. Have you had any mentorship successes? Failures? Let us know!

 

VIA: SitePoint/PHP

Becoming a PHP Professional: The Missing Link - 1/4

When reading various PHP related blogs, Quora questions, Google+ communities, newsletters and magazines, I often notice extreme polarization of skill. Questions are either at the "How do I connect to a MySQL database?" level or something in the range of "How do I best scale my mailing system to send over one million emails per hour without introducing a new server?"

I personally distinguish between 4 distinct levels of PHP prowess (likely applicable to any language/profession): beginner, intermediate, professional and elite.

The extremes

In PHP, beginners learn about variables, includes, form processing. They learn simple logic constructs. They send an email with the help of a tutorial, maybe even touch on an object oriented programming example without actually understanding it. They work with WordPress and modify a couple CSS classes. With this knowledge, they apply for jobs and, unfortunately, usually fail.

Professionals are those who have given good parts of their lives to many projects. They've deployed commercial applications in most if not all frameworks, they've used different databases with PHP efficiently, they visited and/or talked at conferences. They studied design patterns and can easily engineer an entire project on their own from diagrams to execution. They left procedural code far behind.

Elite programmers are professionals who put in the fabled 10000+ hours into honing their skill. They supplement their PHP installations with extensions they wrote themselves, they find bugs just by glancing through source files, they are extremely meticulous about their code layout. They reject all but the most complex projects and find alternative and imaginative ways to solve problems people didn't even know they had. They've written some well received books about the language, spoke at dozens of conferences, maybe even made their own branch of PHP or a highly successful framework or two.

So in all this, who are the intermediate ones?

The missing link

How does one get from beginner to pro and beyond? If one doesn't know anything beyond the basics, how can they improve their skill enough to leave the bad practices behind and start practicing the more advanced approaches? This is a question I get asked a lot by beginners. In order to become a professional, one must first become intermediate.

What follows is a list of what one should go through on the path to PHP fluency.

Abandon spaghetti code

Many people think using classes means you're writing object oriented code, while using functions means you're writing procedural code. While this is false, for the sake of this argument, let's assume the widespread vanilla definition: procedural code is code in which you simply don't use classes and objects, and OOP code is code in which you use classes and objects as much as possible.

My advice is to fully abandon procedural code. Use object oriented coding style as much as possible – write classes, encapsulate logic, think with real world terminology. The performance benefit of procedural code over class based code is negligible when compared to the re-usability that proper OOP code gives you and future developers inheriting your project. A common argument against this is "But, WordPress is procedural!" To be frank, and this might sound harsh, "WordPress developers" are no more PHP developers than people with Instagram are photographers. Please don't take this to mean WP is useless – it's fantastic for blogs, simple websites and one-day projects you don't want to spend too much time on. It's excellent for making a quick buck or for people who aren't too technical, but mastering WP will never make you a professional PHP developer – it's a yarn of spaghetti code that can teach you no proper design principles.

Start small. Think of a real world concept, and try to represent it in OOP code. Work through some basic tutorials and slowly go more advanced. Work on OOP code until you understand classes in general before transitioning to proper frameworks and confusing terms like "Model", "View" and "Controller" – all these are foggy, abstract terms without having a solid foundation in OOP first.

Dissect existing projects

Dive into existing source code wherever you can find it. For example, look up PHP projects on Github, clone them, deploy them locally on your own machine and try to play around with the code. Go file by file, line by line, until you understand what each does.

Look for projects that are well commented and/or documented, well structured, and still alive. Projects last updated in 2008 won't do you much good if you're getting into PHP 5.5 – you'll likely be missing out on the latest and greatest features that could make you stand out in an already overpopulated field.

Learn to set up your own PHP environment

Being able to set up your own environment is a priceless skill. Not only does it allow you to fine tune your setup, it also familiarizes you with building extensions from source.

Abandon Windows for development – if your main desktop is Windows, install virtualization software and run a Linux virtual machine – the case insensitivity of Windows, its line endings, and all other oddities inconsistent with most server environments out there are just asking for trouble, so it's best to develop on a system that most resembles the environment you'll eventually be launching on.

Virtual machines also help you experiment – if something goes wrong, you can just wipe it and start over or do a rollback. You can literally experiment as much as you want without fear of messing anything up. Mastering tools is important, but having a good workbench is too.

Experimenting with your own setups will also allow you to get familiar with the different servers out there – whether to use Apache of Nginx, whether to use neither of them and go with Appserver, and so on.

Exercise best practices early

When writing your own code, make sure you comment heavily with docblocks, indent beautifully and structure carefully. After you build a class, project or library, use well known documentation tools (PHPDocumentor, ApiGen) to extract the docblocks and improve on them.

A good IDE is worth its disk size in gold – getting used to one multi platform editor can help you be up and running in no time when setting up a fresh environment, so you can dive into code instantly without wasting time on setting up keyboard shortcuts and themes. Make sure you back up IDE configuration files on a cloud service like Google Drive, so you have them ready for import at all times even if you need to make a fresh installation. A good IDE is PHPStorm, or if you can't afford it or have no open source projects with which to ask for a free license, Netbeans is a free alternative. Both are multi-platform.

Getting used to best practices early helps you remain consistent and lets other people read your code much more fluently. Find your style and stick to it – you'll help both yourself and others. Try to follow the PSR standards (PSR-0, PSR-1, PSR-2, PSR-3) as closely as possible – they’re called standards for a reason. Most of us use and love them, and they make everyone’s code equally reusable and readable.

A good beginner friendly resource that gives up-to-date hints is PHP the right way – use it to get familiar with the latest best practices, basics of OOP, security, deployment, coding standards I mentioned above, and much more.

Try out different frameworks, choose one

For a long time, PHP was the language with most frameworks out there (JavaScript took over recently). Whether this speaks of the inconsistency of our community or the popularity of our language, I cannot say, but the fact remains that choosing a framework is a daunting task, especially when first starting out.

Having tried most of them, I can wholeheartedly recommend Phalcon as the go-to framework due to its robustness and quality, and the fact that it's built in C and installed as a PHP extension (thus being faster than any current framework in existence). However, trying out different frameworks is an absolute necessity.

When you try them out, you learn about a new approach to a common problem every time. Each framework has its own quirks you'll like and downsides you'll hate but most importantly, you'll learn about the mindset of others (particularly the developers of the framework). You'll see new usages and approaches, and a very good exercise is re-building one of your sample projects in as many frameworks as you can find. This will help you efficiently gauge the efficacy of a particular framework: the speed of developing in it and its performance.

Read

Don't underestimate the hints and tips of others. Read as much as you can – if you keep at it, it doesn't take as much time as you might think. Find good blogs to follow, read the tutorials on this website, traverse questions and answers on StackOverflow, visit the SitePoint Forums, subscribe to newsletters, follow good sources on Google+. Avoid basic PHP tutorial books – they're outdated as soon as they're published – instead, focus on individual snippets and tutorials of useful up-to-date code you can find all over the web. Even if the topic is something you've already covered, try giving it a read – you'll often find that something new can be learned by reading someone else's perspective on the very same thing.

If there's no work, invent some

There is always something to do. Never catch yourself saying "I don't have a project" or even worse, "I'm bored". If you don't have an active project to work on – make one up. Do you use a tool daily that frustrates you with its lack of functionality? Build a better alternative! Have no ideas for new products? Replicate existing ones – try rebuilding a basic Facebook, recreate something you already know exists just for practice.

What's most important is to never stop – there's no amassing 10000 hours if you don't put in the hours! Keep working, keep yourself interested and engaged. Make a simple address book app. Then rebuild it in another framework. Then rebuild it with another database (replace MariaDB with Mongo, for example). Keep busy!

Find a buddy/mentor

It's easier to learn when you have someone to do it with. Find a buddy who shares your passion. Maybe you're one of the lucky few with a partner who shares your geeky interests. Maybe you're in school or university and have peers who would like to get started as well and need companionship in these adventures. You can even find a mentor and receive expert guidance.

Never underestimate the power of a companion – there's a reason The Doctor always has one!

Conclusion

When you focus on all these entries with as much will as you can muster, when you realize it's what you want and keep at it – you're on the road to becoming a PHP pro. Maintain discipline, never give up (even if others around you do) and keep practicing.

If you've got any useful resources you'd like to share with us on how you bridged (or are currently bridging) the Intermediate gap, let us know in the comments below!

 

VIA: SitePoint/PHP

giovedì 22 gennaio 2015

10 web design trends that will change everything in 2015

Some of the web's smartest designers and thinkers reveal the trends and technologies they believe will transform the web in 2015.

In 2014, the biggest web design trends included: grid layouts, flat design, background videos, and the increasing capabilities of HTML5 APIs.

So which trends, technologies and techniques will define 2015? net magazine set out to uncover them by asking 20 of the web's brightest designers, developers and thinkers. 

Here's our list of 2015's defining trends. Some ideas are featured in net magazine's feature. Most contained here are exclusive, and you won't read them anywhere else.

01. Huge background images
Blame Apple for more massive backgrounds images

Front-end developer Benjamin Hollway expects more massive background images in 2015, "used alongside rich typography and subtle parallax effects", largely due to the lead taken by massive brands such as Apple and Google Nexus.

02. Card-based design

Creative director Haraldur Thorleifsson says card-based design will be big: "Content needs to fit on different types and sizes of screen, and cards are the easiest way to make that work across platforms." He adds this presents a design challenge, since cards can be dull, "but we're seeing fun, clever takes on this from companies like Google".

03. Digital-first branding

Clearleft founder Andy Budd (clearleft.com) says "as more companies realise their customers' primary experience with them is online, we'll see more digital-first-approaches to branding". He predicts companies "ditching traditional branding agencies who treat the web with the same care as a branded mug", instead "commissioning digital agencies to conceive a brand that works first online before filtering down to other channels."

Ghostly Ferns founder Meg Lewis (darngood.co) adds this may result in "more brands with responsive, fluctuating logos," which will "force designers to think about a logo from 'big picture' to 'minute detail' as it scales".

 
04. Open data

Sally Jenkinson says open data's been on the rise, but many digital spaces remain "more closed than ever" and so "leaders such as The Open Data Institute are working to promote more openness". She reckons this will gain public awareness in 2015, and projects will respond accordingly, in terms of publishing and consumption.

Clearleft's Andy Parker says we'll therefore see "more public and private companies making data and content available". In turn, this will result in "some pretty spectacular services being created, like the Cern sandbox".

05. Responsive design – evolved

Designer Victor Erixon (minimalt.se) expects the industry to "continue maintaining simple and minimal aesthetics," with the web "becoming fully customised for different viewports".

But others see responsive design going further. Jonathan Smiley (jsmiley.me) thinks we'll see "responsive design practices become more important in native apps," in part through a proliferation of wearables. "Apple Watch, for example, relies on a responsive-like flow to accommodate a small screen, and so while 2015 isn't the year the web and native become the same, it'll get us much closer."

 

06. Privacy

Designer Laura Kalbag (laurakalbag.com) says we've long "designed for security, so people can trust forms and checkouts with their information". Now, as people become aware of how data can be exchanged with third parties, "they'll be reluctant to share it without good reason — and rightly so".

07. Isomorphic JavaScript

Aaron Gustafson has a different take on JavaScript frameworks

Web design author and practitioner Aaron Gustafson has an alternate take on investment in frontend JavaScript frameworks like Angular and Ember: "Development benefits can be great in terms of speed of development, but there are costs to using this approach. JavaScript is the single biggest point of failure in any web-based product. Unlike on the server side, we do not control the execution of code in the browser."

He therefore reckons we'll see more use of isomorphic JavaScript, for companies that have heavily invested in JavaScript for their site infrastructure: "It offers improvements in the areas of performance, SEO, and maintainability to boot. Airbnb and Twitter have moved to this approach. Others will surely follow."

08. Iteration

Designer Robby Leonardi mulls that perhaps 2015's big trend will be iteration on what we already have: "We just had trends such as responsive and flat design, and it will take time for another big thing to happen."

By contrast, he sees enhancements on existing concepts and technologies, with increasingly sophisticated web layouts, better typography, and more designing in the browser.

09. Vibrant design
Google's Material design is set to inspire designers

BaseKit co-founder Richard Healy believes Google's Material design specification – intended to combine the texture and tactility of paper and ink with the 'imagination and magic of digital' – will inspire designers.

He told us: "Think bold, graphical and intentional. We're talking vibrant, unexpected colours, contrasted with subdued and muted environments; large-scale typography, soft directional lighting and shadow; the use of responsive design best practices; and meaningful motion – carefully choreographed animation that provides fluid, seamless touch transitions and, more importantly, delights users."

10. Web components meet adaptive design

Developer Aaron T Grogg predicts "web components and adaptive development will combine to create a new style of web development". Someone will then fashion a "snappy acronym for this approach, which will cause all job ads to now require it".

By adaptive, Aaron clarifies he means making decisions on the server regarding mark-up to send a user, usually depending on the device being used. "When you combine the power of adaptive development with the flexibility of web components, I think we are going to see very creative solutions from designers and developers.

Hopefully, we will still be creating mobile-first, responsive, one-site-for-all-devices, but making subtle differences will be powerful tools in our toolboxes."

Words: Craig Grannell

Craig Grannell is a writer, designer, journalist and long-time contributor to net magazine. Follow him on Twitter @CraigGrannell.

 

VIA: Creative Bloq

5 steps for mastering web animation

Rachel Nabors for net magazine

Award-winning cartoonist and interaction developer Rachel Nabors walks though how to get started in web animation.

It's never been a more exciting time for web animation. With user interface designers and interaction developers increasingly relying on animation to improve their online experiences, demand is on the up. And with better in-browser tools on the horizon thanks to the new Web Animation API, 2015 is set to be the year web animation explodes as a creative discipline.

But where do you start? Is CSS better or JavaScript? Which tools won't break the bank and how do you crate interactive prototypes for developers?

Whether you're an illustrator looking to take your skills online or a designer hoping to master a profitable new market, award-winning cartoonist and interaction developer Rachel Nabors shares valuable advice for getting started in the exciting world of web animation.

And if you're all fired up to learn a new skill, check out Computer Arts 235: Make 2015 Your Best Year Ever – a bumper issue packed with everything you need.

01. Getting started

I'm an illustrator. I don't have a coding background but I'd like to start experimenting with web animation and I'm not sure where to start… Help! Is CSS or JavaScript better? What are the best resources? Are there any pitfalls I should avoid?

Rachel Nabors: The best place to get started learning web animation is codepen.io. This site lets people play with CSS, JavaScript and HTML, share their examples, and make copies or "forks" of each others' works. It's a great place to get inspired and poke at code while learning.

I also cannot stress the importance of learning CSS and JavaScript. JavaScript is required for advanced animation with the Web Animation API, Canvas, WebGL, GSAP. I recommend starting with Cody Lindley's JavaScript Enlightenment books.

02. Web animation tools

What are some good tools that won't break the bank for digital drawing?

RN: I recommend Manga Studio and a Bamboo stylus to anyone wanting to break into drawing digitally. I'm sure there are other products and combinations out there, but these two together are affordable and deliver beautiful lines.

03. Storytelling

How can I incorporate storytelling in web?

RN: As for incorporating storytelling on the web, that's a question with a much longer answer. For instance, I run an month-long online course on the matter at rachelnabors.com/training.

I recommend reading books about storytelling from outside web development. Scour your local library for books on film, writing, cartooning, animation, books that have "story" in their titles and descriptions. Take one of these up as a side hobby, and soon you'll find it forms a feedback loop with your more technical work.

04. Prototyping

Do you prototype your animations in something like After Effects or Framer first?

RN: The web animators and UI designers I know send their materials to development teams with little movies of how they should look in action. They often use the tools they are most comfortable with designing motion in: After Effects and even Flash!

I've met other teams who send specific motion and timing coordinates to developers as well. And others do a fair amount of interactive prototyping in tools like Framer or Edge Animate.

05. Web animation API

Will JS animation dominate the future with the arrival of new Web Animation API?

RN: Meaningful animation will always require some amount of JavaScript. Truly interactive animation will require gobs of it. The Web Animation API will do two important things.

It'll open up the browser's rendering engine for browsers and extension developers to build better in-browser tools for manipulating animations, and give animation library developers access to hardware acceleration currently only available to CSS animation. Full support cannot come soon enough!

Words and image: Rachel Nabors

Rachel Nabors is an interaction developer and award-winning cartoonist. When not biking around Portland, she makes interactive stories with code at her company TinMagpie.com. You can find more of Rachel's pro web animation tips and tricks inside net magazine issue 264 - on sale now!

 

VIA: Creative Bloq

Screencast: Create a Responsive Video Header with Bootstrap

Video headers add a personalized touch and are used on sites such as Airbnb, among others. The best thing is that they are really simple to make. Watch and learn how to create a responsive full-width video header for your next website.

In this tutorial I will demonstrate how to use HTML5’s video element, some CSS3, and the Bootstrap framework to code the video header.


 

VIA: SitePoint

Getting Started with Skeleton, the Simple CSS Boilerplate



In early December, Skeleton released a new updated version. In fact, it was its first update for almost two and a half years. That’s good news for those of us who have used Skeleton in the past and loved its simplicity!
In this article, I’ll introduce you to this lightweight CSS framework. I’ll start giving a brief intro about it and presenting its major features. Then I’ll show you how to use it in a real project, which will be based on a demo page that I’ve built.

What is Skeleton?

As mentioned above, Skeleton is a lightweight CSS framework (or boilerplate, if you prefer this definition) created by Dave Gamache. More specifically, it’s two CSS files: the popular normalize.css file and the skeleton.css file. The latter contains the framework’s styles, which are limited to around 400 lines of uncompressed code.
The most important part of Skeleton is its grid system, which I’ll analyze later in this article. Additionally, the framework provides basic styles for common HTML components like buttons, lists, tables, and forms.
To get the latest version of Skeleton, you can visit the website and download the zipped folder. An alternative option is to fork the GitHub repository.
After you download and extract the compressed folder, your file structure would look like this:
Skeleton/
├── css/
│     ├── normalize.css
│     └── skeleton.css
├── images/
│     └── favicon.png
└── index.html

Similar to frameworks like Bootstrap and Foundation, Skeleton also uses a mobile-first approach. However, as discussed, it doesn’t include the large number of components that those frameworks offer; it contains only some fundamental CSS rules that help you kick-start your development process.

It’s worth mentioning that Skeleton is fully functional in all the latest browsers including IE9+. Finally, you can also opt for the Sass or Less extensions of Skeleton.

Versions: Latest vs. Previous


There are many differences between the current version and the previous one. The table below summarizes the most important differences:


FeaturesV2.0.2 (Current Version)V1.2 (Previous Version)
CSS files23
Mobile-First Approach?YesNo
Grid12-column fluid grid16-column fixed grid
Typographic Unitsrempx


Grid


Skeleton’s latest version defines a mobile-first 12-column fluid grid, consisting of rows and columns, as with all CSS grids.

An Example Grid

Rows have to be placed inside a wrapper that can have a max-width value of 960px. To create the wrapper you define a div element and apply the container class to it. If you’re familiar with Bootstrap’s grid, you might know that Bootstrap uses the same class name to define its wrapper.

The width of the wrapper element in Skeleton varies depending on the screen size. In any case, as already mentioned, it can’t exceed the 960px. The table below shows its possible values:

Viewport Width Container Width
< 400px 100%
≥ 400px 85%
≥ 550px 80%

Columns are nested inside a row. They scale up to 12 for each row. To set up a column you have to define a div element and assign it two classes. First, you add the class that is responsible for specifying the column widths. To achieve this, you can use any class from one to twelve or the one-third, two-thirds, and one-half classes.

The second class is responsible for setting the column margins. Possible classes are columns and column. If you define the column widths with the first option (e.g. using the two class), you should use the columns class (instead of column) as a second class. The exception is when using the one class, which can be equally combined with the columns or column class.

While other frameworks support nested rows, Skeleton recommends not nesting rows within columns. Moreover, Skeleton’s grid system provides extra classes for offsetting your columns. Offset classes (e.g. offset-by-two) allow you to increase the space between columns by adding a margin-left property to them.

Utilities


As mentioned, beyond its well-structured grid, Skeleton comes with additional predefined styles. For example, there’s the button class, which allows you to style an anchor (a) element as a button. There’s also the option to give the button a light blue background-color using the button-primary class.

Another example is if you want to float an element to the left or right, you can add the u-pull-left or u-pull-right class to it. You can also use the u-cf helper class for clearing floats.

Those are just a few of the examples of utility classes bundled with Skeleton.

Using Skeleton


Now it’s time to use Skeleton’s powerful features in a demo project. We’ll explore three different examples.

The image below shows the desired layout on small screens and up (≥ 550px) for our header element. Notice that we split the row into 2 equal-sized columns. However, for extra small screens (< 550px) we want the columns to be stacked. That means each of them will expand to cover the entire row’s width.


Skeleton example 1

Here’s the HTML:
<header>
  <div class="container">
    ...
    <section class="services">
        ...
      <div class="row">
        <div class="one-half column">
          ...
        </div>
        <div class="one-half column">
          ...
        </div>
      </div>
    </section>
  </div>
</header>

At this point we should recall that Skeleton supports a mobile-first approach. This means when the browser window has a width less than 550px, the following code snippet is executed:
.column,
.columns {
    width: 100%;
}

This ensures that the columns will be stacked. Next, when the window’s width exceeds the 549px, Skeleton’s grid becomes active causing our columns to occupy 50% of the row’s width (as indicated by the class name one-half). Of course, our layout is based on Skeleton’s default breakpoints, which we have the option to change.

Note: Instead of using the one-half, column class pair as class names, we could have used the six, columns pair, which would produce the same result.

Let’s look at our second example.

Below is the layout of our section.about when the viewport size exceeds the 549px.

Skeleton Example 2

Notice that the first column occupies two-thirds of the row’s width and the second one occupies one-third. Again, for extra small screens our columns are stacked and have widths of 100%.

And the relevant code:
<section class="about">
  <div class="container">
    ...
    <div class="row bottom">
        <div class="two-thirds column">
          ...
        </div>
        <div class="one-third column">
          ...
        </div>    
    </div>
    ...
  </div>
</section>

Note: Instead of using the two-thirds, column and one-third, column pairings as class names, we could have used the eight, columns and four, columns pairs respectively, with the same results.

Let’s see our last example.

Here’s how we want to structure our footer element:

Skeleton example 3

In this case, the target row consists of one column. This occupies about 65.33% of the row’s width. We also want to center it. For this reason, we use the offset-by-two helper class.

The corresponding code can be found below:
<section class="contact">
  <div class="container">
    ...
    <div class="row">
      <div class="offset-by-two eight columns">
        <ul>
            <!-- list here... -->
        </ul>
      </div>                  
    </div>
    ...
  </div>
</section>

Below is the embedded demo on CodePen:




Conclusion


In this article, we’ve looked at the main features of Skeleton, a CSS boilerplate that can speed up your front-end development. Of course, keep in mind that Skeleton isn’t a one-size-fits-all solution for all projects. It’s simple, yet limited.

Have you used Skeleton in any of your projects? Do you like its simplicity or do you prefer working with a more comprehensive framework like Bootstrap or Foundation?


VIA: SitePoint

8 Things I Wish I’d Known When I Started as a Web Developer

I have been in web development for more than five years and it’s been quite a journey — trying out different technologies and experimenting with different styles. I’ve been successful at times, but I’ve also had my fair share of disappointment. In this post, I’m going to talk about certain realizations I’ve had over the course of my life as a web developer, with the hope you can learn from my mistakes.

1. Write Clean Code

Source: funny-memes.org

Source: funny-memes.org

The first thing you realize when you start making large applications is that a huge amount of time is required for debugging. Often, you’ll spend more time debugging than writing new code.

In such a situation, it’s highly important you write properly indented and commented code, which adheres to best practices. Imagine you have hundreds of lines of code, and you have no idea what’s causing a small bug. What’s worse is that if you write unreadable code, you’ll probably fail to understand what each snippet does after some time. Are you sure you want to go down that path? Here are some tips to make writing clean code easier.

2. Language first, framework later

Source: Giphy

Source: Giphy

People often first learn the tricks of a framework, and then move on to the language. That’s actually not the right way to go.

The popularity of Django can be attributed to the strengths of Python — so it’s important that you get comfortable with Python before trying out Django and not the other way round.

The simple reason here is that if you know about the underlying language, it helps you understand how the framework works. If you have no idea about the trades of a a language, there is no way you will understand why something is done a certain way in the framework.

3. Learn JavaScript, not jQuery

Getting a bit more specific than the idea raised above, I would like to give special emphasis to JavaScript, which is the most accessible language in the world. Any device with a browser is capable of running a JavaScript application.

The mistake that young developers often make is to “learn jQuery”. Questions like these on Quora suggest that jQuery is a very popular option among people who have no idea how the underlying JavaScript works!

jQuery is just a set of wrapper functions written over JavaScript and the only reason people prefer jQuery is because of the fewer number of lines of code required. However, recent versions of JavaScript (or ECMAScript as it is originally known as) have made the syntax more user friendly, making many jQuery functions obsolete.

I am not saying using jQuery is wrong. I am just telling you to follow the correct learning path. If you have no idea about closures and namespaces in JavaScript, how would you explain the use of “$” in jQuery?

4. Don’t just read, implement

I’ve often seen developers read through tutorials or sometimes even whole books without anything much to show for it. However, my biggest concern is how much would you retain if you just read?

If you want to learn Ruby on Rails, try to develop a small application as you are going through the documentation or a set of tutorials. If you want to try the MEAN stack, get it running in your local machine and explore the different options — that’s the best way to learn!

5. Jack of all trades, Master of one

It’s good to explore new technologies, but one must remember to stick to one for most purposes. It’s always tempting for beginners to learn multiple languages at the same time, but it’s advisable to stick to one until you develop a certain level of mastery over it.

Once you have a go-to language for your day-to-day needs, you can move on to new ones. You may also changed your preferred language in this process, but attempting to master one before you move on to others is often a wise decision. Here’s some advice for choosing which one to start with.

6. Learn version control

In today’s world, it’s very rare that you work on a project alone. To collaborate with others, you need to learn something called version control!

Developers usually don’t dive into version control until they absolutely need to do so. However, as version control is necessary to work in a team, it’s a good idea to understand how it works and the basic commands that get you started early on.

7. Learn from the work of others

Mastering a technology on your own is great, but sometimes you learn a lot by just looking at the code of others. Be it your colleagues or random tutorials on the internet, try to find why someone approaches a problem in a certain way — and ask questions if necessary.

It’s also important for developers to realize that it’s impossible to know everything, but the knowledge is out there — you just need to Google it. As a beginner, if you’re stuck there is high probability that someone like you had the same problem in the past and the solution is somewhere out there in the internet (this often happens to the veterans too!)

8. Ask for code reviews (and enjoy them!)

Over the years, code reviews have immensely improved my programming skills. Proper code reviews take time on the part of the reviewer, so you should always ask others to review what you have written — your peers as well as mentors. It helps expose loopholes in your approach, and makes you learn. If you find someone who genuinely takes interest in reviewing your code, take their reviews seriously. Here’s a look at an advanced way to code review.

Lastly, never take code reviews personally. Code is like art — it’s difficult when someone points out errors in what you have created, but code reviews can only make you better — provided you take them the right way!

Conclusion

This post stems from my experiences as a web developer and what I have learned from events that have shaped my life. For further reading, check out this article on how to be a good developer.

 

VIA: SitePoint

Copyright © Niente Canzoni d'Amore | Powered by Blogger

Design by Anders Noren | Blogger Theme by NewBloggerThemes.com | BTheme.net        Up ↑