Vagrant was unable to mount VirtualBox shared folders. This is usually
because the filesystem "vboxsf" is not available. This filesystem is
made available via the VirtualBox Guest Additions and kernel module.
Please verify that these guest additions are properly installed in the
guest. This is not a bug in Vagrant and is usually caused by a faulty
Vagrant box. For context, the command attempted was:
mount -t vboxsf -o uid=1000,gid=1000 src /srv/src
The error output from the command was:
mount: /src/src: unknown filesystem type 'vboxsf'
Issue tracking is a very annoying topic when dealing with disorganized development. When part of a team working on the same project, using some sort of tracking system like Jira, trac, Bugzilla, or any of the million and a half other trackers becomes a natural requirement that eventually gets implemented into the workflow. A problem I've had in the past is the unwillingness of a client to want to use one of the systems. I had to figure out a way to appease their desire to not bother while keeping items in some sort of order and to provide historical records of requests and conversations.
For the past month or so, I've been working on building a new application for a project from scratch, and I wanted to take the time to learn another framework in doing so. I really am a huge advocate for using off-the-shelf software like drupal, magento, and phpbb when you can, but I still love getting my hands dirty. The project has gone through several massive iterations and revamps over the years since its first concept in 2003, and I finally decided on something viable a couple years ago. The project is Wow! Merchant if anyone's curious and following along. I've been using Zend Framework 1 for years, and I've grown to love and hate it. Apparently there are ways to use it for some kind of automated development, but I use it for a skeleton MVC system with a registry and library. Key up on the automation point for it'll return later.
To the uninitiated, scrum is an agile development model that focuses on short term development periods called sprints. If you can't fit a task within a sprint, then that task needs to be split up into subtasks so those may fit. You define what you're going to do each day and commit to it. After each sprint, you're supposed to have something deliverable. In software, that translates to a deliverable program at the end of every sprint with added features and bug fixes. A caveat to this is the adherence to using the items assigned each sprint as documentation.
Some time back, I came across a php challenge where the goal was to create a calculator of bowling scores based on frames in the fewest number of characters. In practice, you don't want to try this kind of optimization because it doesn't help anything. The reasoning is that php is interpreted and parsed. If you were doing assembly programming, or low-level C instead, then you'll find some small improvement with a couple of the tricks, but with php, it's just a mental exercise. I wanted to explain the entire process, from nothing to the finished product.
So I have been sitting on this idea for a while, and every time I mention it, people seem to be shocked at the implications. I know I'm not the first to say so, but I seriously think that Valve is working towards an end-goal of a linux-based console running a Steam OS. Perhaps not an actual Steam OS, but a customized operating system that boots directly to Steam in the same guise as a Firefox OS. It only takes someone with the ability to see a trajectory to see where they are going, and with the recent news from ars technica about them going after some hardware, it puts their point on that trajectory further down the path than I had thought.
If you're ever wondering whether to roll your own software, use a framework, or use an existing content management system, CMS, for a project or to learn, here's the advice I give everybody.
Roll your own, then adopt an existing framework or CMS so you don't have to worry about everything you don't know you don't know.
This is actually a very common topic I've run into when working on large projects. I'd bounce the idea off other seniors, and we're pretty much all in agreement with it. If someone wants to learn, have them write a framework, then a CMS on top of that framework. They'll quickly realize problems such as short-sightedness on design, incorrect estimation of the time, and most importantly, finding out what they didn't know prior to starting. It's an extremely insightful task to undertake, and I recommend anyone trying to learn to do it.
For those of you who don't know what black box development is, I'll explain the concept a little first.
There are two main types of development, black box and white box; sometimes mixing of the two would naturally be referred to as grey box. Black box development is where the outside people have absolutely no idea what's going on inside, and it's basically a little magic box that'll churn out some sort of result. You can reverse-engineer the internals if you provide enough variable inputs and record their outputs for analysis, but generally, it's voodoo. The term comes from not being able to see in the dark; it's a void, like a black hole in the cosmos.
The opposite of black is white, so a completely open system is referred to as a white box. I've also heard glass box because of its transparency, but the balancing of colors is easy to remember. When you're developing a system, you usually understand all of what you're working on, so the system is transparent to you, hence a white box development.