On the Laravel News site there's an interesting post about learning "just in time" so you can not only keep up with the latest knowledge but not have to worry about things you don't actually need to know.

Technology—including the web—moves insanely fast. It can be intimidating (often annoyingly so) to try to not only consume the content constantly served to us, but also retain it. After all, isn’t the point of sharing information to learn from it? This just-in-time knowledge can be an unfriendly reminder that, no matter how hard we try, we will have a difficult time keeping up with the newest trends and tech.

[...] Luckily in tech, most of us have to keep up to date on software and hardware to be successful at work. But what if we’re swimming in a project at work and don’t have time to look into the new technologies? What if it’s nearly impossible to bake new knowledge into our jobs?

The article talks about methods for "knowledge gathering" you can do in small bites during your day, making use of them to keep up with the latest trends and technology. It also talks about retention, how sleep and training play into it and the where researching topics more in-depth can help.

If you've never heard of the powerful tool and you need automation around creating and configuring multiple virtual machines, you really should check it out. If you're curious as to how it's being used and what kind of things it's used for, check out this new post from Erika Heidi based on some research she recently did (and a survey she received some good feedback to).

From 11 to 14 of January, 720 Vagrant users from different sources (Twitter, IRC and the official Vagrant mailing list) answered a quick form I created to find out how people are using Vagrant. I’m currently in the process of writing a LeanPub book about this tool, and I was really curious especially about the provisioners usage.

She's put together the results in the form of an easy to read infographic with details about:

• The most popular provisioners
• The percentage of boxes running with OS
• The percentage of languages on the boxes
• The OS most Vagrant users use

...and finally the answer(s) to the question of "why vagrant?" but I'll leave it to you to read the post to find out that one.

Anna Filina has a new post to her site today suggesting that developers are like athletes, they need to practice before they can be good at what they do.

Think of a developer as an athlete. He or she is aiming for a medal in a competition. A figure skater can't just perform a triple axel in the Olympics after seeing it done on television. This requires a lot of practice, so that when the time comes, the performance is flawless. Of course, programming doesn't have to be flawless. One must remain pragmatic, yet it still requires practice before a concept can be safely implemented without breaking the project or missing deadlines. Who will pay for that practice?

She relates the development manager to the coach of a sports team, being the one that guides the developers into being all they can be and trying out new ideas in the process. She also recommends making use of idle time between projects to prototype, do R&D and learn in general.

Developers need a sandbox. If you don't give it to them, you can end up with one of the following issues. Your entire project could become a sandbox, making it unstable. [...] If you want your developers to get better, allow time for practice, not just learning. It's necessary, easy to do when planned and provides countless benefits to your company. Let me know how that advice worked out for you.

Cal Evans, following some "unscientific research" he did on the subject, has posted some interesting findings about technology conferences and why people attend.

Those of you who follow me on twitter (@calevans) know that recently I asked for opinions on conference attendance. I’ve collected what I learned in this blog post.

He asked three groups of people - speakers, non-speakers and managers - for their opinions as to why they attend or send their developers to these events. his results were interesting, finding that slightly more people were looking for networking than just the training you get in the sessions. General community interaction also scored high. On the flip side, the things that mattered most to the managers were the training and a good price that seemed right for what was offered.

Both sides are reinforced by comments from people who submitted to the survey, both well-known PHPers and general community members alike.

Stuart Herbert is looking for some more input on a different sort of question (one that I can't say I've seen asked before) - what are some of the issues with default Linux distribution PHP installs.

Most Linux distributions ship with packages for PHP, but not everyone is happy with these packages. If you’re not happy with the PHP packages for a specific Linux distro (no matter how obscure), I’d love to hear what you think the problems are and (if possible) what the correct solution should be.

Just leave a comment on the post with the things you might have noticed. Comments already made reference issues in Debian/Ubuntu, RedHat and a few other more general "state of PHP packages" comments too.

New on the Developer Tutorials blog today is this post offering up a few ideas (five of them) on how they think you can become a better programmer.

In this post, I'll outline five ways to be a better developer, improve your productivity, write less code and achieve more with your web applications.There's always more to learn when it comes to PHP development. New core functions, new frameworks, new design patterns, new code documentation styles. Here are some of the best ways you can become a better PHP developer.

His five suggestions are:

• Read the manual
• Browse through some code
• Learn a new framework
• Research
• Learn OOP

I can understand where he's coming from on all but the third one - frameworks are nice, but it's more important to get the fundamentals down first before making a framework some of your first experience.

On his blog, Nick Halstead shares a few tips he's worked up to help developers that might be having a hard time with coding issues - a few steps towards solving programming problems.

Early on in most people's programming careers problem solving is a large part of your day to day job. As you become more experienced you find that many programming patterns that you have used before can be reapplied. You then start working on larger and larger projects and the problems tend to be more about solving architectural problems rather than logic related ones.

Included in his list are things like "Talking it through", "Brainstorming", "Breaking it down" and "Research". This last one can be one of the most important and can save tons of time in the long run. With tools like Google and other sites, there's no reason to check before you start a project to see if there's someone out there that might have already done it (and it might be more well developed).

On his blog, Nick Halstead shares a few tips he's worked up to help developers that might be having a hard time with coding issues - a few steps towards solving programming problems.

Early on in most people's programming careers problem solving is a large part of your day to day job. As you become more experienced you find that many programming patterns that you have used before can be reapplied. You then start working on larger and larger projects and the problems tend to be more about solving architectural problems rather than logic related ones.

Included in his list are things like "Talking it through", "Brainstorming", "Breaking it down" and "Research". This last one can be one of the most important and can save tons of time in the long run. With tools like Google and other sites, there's no reason to check before you start a project to see if there's someone out there that might have already done it (and it might be more well developed).

According to this new post on the MySQL Performance Blog, PHP has a bit of an issue when it comes to working with integers.

Until recently I thought that currently popular scripting languages, which mostly evolved over last 10 years or something, must allow for easier portability across different platforms compared to ye good olde C/C++.

However, PHP just brought me a new definition of "portable" - and that was when working with... integers.

He points out that PHP isn't able to correctly handle unsigned integers ("and converts values over 2^31 to signed"). He goes on to talk about how this differs between platforms too (32 vs 64 bit) and some of the research he did to find out just what was going on (including some code examples to illustrate the point).