[code lang="php"]$binary_image = drupal_http_request($url);[/code]

After checking the response code to make sure it was successful, use the Drupal function file_save_data() to physically store the file into whatever directory you want to store the image file in.

[code lang="php"]
if ($binary_image->code == 200) {
$filepath = file_save_data($binary_image->data, $save_to, FILE_EXISTS_RENAME);
if ($filepath !== 0) {
// attach other relevant information as well
$fileinfo['filepath'] = $filepath;
$fileinfo['filesize'] = filesize($save_to);
$fileinfo = array_merge($fileinfo, getimagesize($save_to));
return $fileinfo;
}
[/code]

The physical file should be saved but just because you’ve saved the file in the directory does not mean that Drupal is aware of the file. In order for that to happen, you also need the mime type, the file size, and the filepath and manually insert into a node. Once you’ve got those, you can create a node and insert those values along with the rest into it.

[code lang="php"]

// create a node
// add the file's information into the node
$node['field_thumbnail'] = array(
array(
'list' => 1,
'data' => array(
'alt' => '',
'title' => '',
),
'fid' => $fid,
'uid' => $user->uid,
'filename' => $resource['logo_file'],
'filepath' => 'files/_thumbnails/'.$resource['logo_file'],
'filemime' => $info['mime'],
'filesize' => $info['filesize'],
'status' => 1,
'timestamp' => time(),
'alt' => '',
'title' => '',
'upload' => '',
),
[/code]

This will make Drupal recognize your files. Everything should be gravy. Hope this works for you.

By the way, for all of you already on Drupal 7(lucky you), file_save_data() saves the data and automatically updates the database with the file information.

In mysql, the mysqldump command works great for this:
mysqldump –verbose -user -h [hostname] -p[password] [database_name] > file.sql

When importing a sql file, just go the other way:

mysql -u [username] –verbose -p[password] -h [hostname] [database_name] < file.sql

This two commands will make importing and exporting databases a snap.

Do you love to run or jog? Training for a marathon or 5K? Running Expo allows you to connect with the Facebook user community and create your own digital running route information using Google Maps. Users can search on nearby routes that other people have saved against their profiles as well. For security purposes, we made sure that all routes have access levels. Each route can be made viewable by everyone that is using the Facebook application [public], seen only by your Facebook friends [shared], or be viewable only by you[private].

The future of this project looks bright. A big shout-out to the lead developer of the app, Seth Cardoza for having the vision and bringing me on board. For now, one of the main responsibilities that I will have is to make sure that the word gets out about Running Expo and getting other people to realize it’s value in the Facebook app-space. Without giving away too much, the primary focus of the next iteration will be to hook integrate much deeper with the Facebook platform. So stay tuned.

Please look around and let me know what you think. I would love to hear some feedback. Hope you like the app as much as I enjoyed making it!

It helps you record your solutions and store it in one centralized location. How many times have you come across the same problem when working and not recall that pivotal eureka moment that let you arrive at your solution? Even if your solution is not made explicity in your notebook, even retracing  the steps taken to achieve your answer will help you jog your memory faster than anything else can.

Engineering notebooks can help you to reveal previous trends. The items that wasn’t so obvious when you are in the thick of it. Things such as individual workflow habits and the effort spent on each task.

Documents a history of work as evidence Working in a creative role, it is sometimes hard to quantify your level of effort against a certain task or group of tasks. When it comes to software development, it seems there are always items that have not been taken into account of in the official project plan. We’ve all been there. There’s always “that one other thing” you have to do before you get into the main task at hand. Before you know it , the level of effort it takes to accomplish the periphery tasks snowball out of control. Next thing you know, your boss is hovering over your desk demanding to know why a task that was slated for half a day has been unresolved for a week. An engineering notebook can help you persuade them by showing them exactly how much effort is going into finding a solution. (Of course, it’s your job to estimate tasks responsibly but that’s another topic altogether).

You can set up your engineering notebook with as much flexibility as you require. Honestly, any notebook would do but what works for me are unlined spine-bound notebooks.  I feel that unlined ones are important because they allow me the flexibility to use the writing space any way I choose to. Doodle, scratch out, mindmap – it’s up to you. Marble composition books are nice but I personally went with a higher class of notebook(I am a bit of a snob when it comes to this sort of stuff). The Moleskine Cahier was my choice because I am such a big fan of Moleskine and their legacy. So, when I came across their soft-cover notebook series I knew it would be perfect for what I needed. A little bit on the pricey side but well worth it if you’re into quality. $16.00 will get you a package of 3.

On a typical day, I start off my entry in my notebook by writing the date at the top. Page numbers work for some but I like making my table of contents using dates as my points of reference instead of page numbers. That way once you complete a significant milestone, you can put the starting date and ending date in your table of contents along with a brief description of the milestone as your description. Most people make checklists of tasks to do for the day. This can either be a list of pending tasks or just an aggressive three-point agenda that simply has to get done. Another common thing to do is to start providing a small summary of a sizable activity you are doing. I find that the extra mental effort involved in writing down clearly of what I am doing, why I am doing it, and what the expected result is keeps me focused and motivated to push ahead with the task. It’s important to make these messages meaningful. We don’t need any pointless essays or formal pseudocode. Likewise, engineering notebooks should not be a place to collect meeting notes. Use scraps of paper or a mini-legal pad for that. Once you have had time to internalize the meeting notes, then you should record whatever you feel is relevant to your individual workflow. Test results, case studies, and task-switching events are all acceptable items to place in your notebook as well. Remember that what you are trying to go for here is to capture the thought process involved in solving a particular problem. Don’t worry about seizing every minutiae of work into your notebook. It’s there if you need it and you are encouraged to use it.

In the end, the fact remains that you always need to be ready to capture valuable ideas when it hits you. Those precious flashes of insight come too far and few between. They cannot be forced out into stark reality, only encouraged. By keeping a recorded design journal, you’ll be able to document your work activities, encourage creative thinking and maybe even catch a glimpse of your next great idea hidden just between the lines. What are some ways that you record your design work?

One way of keeping track of tasks is to display the progress of each task (hours remaining till task is complete) in a location that everyone involved in the project has easy access to them. This could be anything from a poster sheet to a whiteboard or even a persistent online message board – as long as it is big enough and persistent to contain all the important tasks that require tracking. Also, make sure that each member of the team understands the purpose behind these information broadcasting tools and encourage them to update it on a regular basis. A good time to update the whiteboard may be every time code is checked in to your source management system(svn / cvs / git).

In the long run if the boards are respected and honored for their purpose both the project management and development teams can spend less time on “figuring out where we are” and more time trying to figure out the next steps to take towards a successful launch date.

Developers can tell when they have a good project manager on board with them . They look forward to the chance of working with them. You are:

• comfortable and conversant with technology. Ideally you ought to have some technical experience behind you.
• you exercise courage and patience when interfacing with the business and technical personnel. You can handle whiny programmers, unrelenting clients, and the crushing weight of looming deadlines and you make it look easy.
• you are constantly looking for and communicating solutions to decrease the burden of the programming team. We understand that you’re not on the same level as the dev team technically. Get involved anyway. You’ll only sound stupid the first few times but you may be able to catch a glimpse of how hard the problem truly is. This also takes a bit of courage.
• you act as a buffer for the development team. Great project managers are resilient and don’t fold under pressure.

The development team can very quickly peg a bad project manager as well. Don’t let this happen to you. As soon as a project manager is seen as not being effective at their job, the word spreads through the development team(s) like wildfire.

Want to get on the development team’s bad side? All you have to do:

• is not know what your team members are doing at any given point in time.
• manage multiple teams assigned to the same project and stare at us blankly when asked where the other team is on their deliverable items.
• don’t ask questions about the technology. In fact, remove yourself from as many technical related discussions as you possibly can. This is a very good move. Especially for you.
• compare our progress with your other successful software projects and inquire innocently why it’s taking so long for our team to finish.
• be at a level technically where even spreadsheets are a black art to you.
• pretend to listen to important developer feedback and then inform the development – yet again – about the fast approaching deadline as if we were all oblivious to begin with.

And there you have it. If you have most of the qualities of a good project manager, that’s great. Know that even if your team doesn’t necessarilly shower you with praises every day, they do have that respect and will readily give you their valuable time to hear your feedback. By reading this, you realize that you’ve got some qualities of a bad project manager, get better. Fast. Start now. Engineers are a very forgiving type of people. If we realize that there is a willingness to change on your part, most of us will see that and help you along. In fact, I think that there are times when developers need to step up and make sure that project managers are meeting the expectations of the entire team as well. As a developer, what would you suggest your project manager do?