Code

You are currently browsing the archive for the Code category.

For people installing Linux the first time, the world can sometimes seem like a minefield of technical jargon and unfamiliar concepts. Understandably, this disillusions many: the Ubuntu Testimonials and Experiences forum has a tendency to alternate between page upon page of unmitigated pontificating to the converted, and trollish cries of “ZOMG why u make ubuntu SO COMPLICATED!!!!1111111???????”

A common stumbling block comes before anyone’s even managed to start Ubuntu for the first time: working out what to do with the strange ISO file that comes down the line when you click the “Download Ubuntu” link. Thankfully, Windows 7 features an ISO burner by default, so that problem is somewhat mitigated – however, there’s still potential for foul-up.

In the past, people have copied the ISO file to the CD using Windows Explorer, and tried to extract it and find another image file contained within. Consider, also, people without Windows 7: for this, people have to download third-party software to create their Ubuntu CD. This is likely to scare off new users.

One way around this is to use Wubi – however, this only creates an installation inside an existing Windows install, which is far from ideal in many cases. In interface terms, however, it’s definitely on the right track. Read the rest of this entry »

Tags: , , ,

vb6

In a rather astonishing move, AQA (incidentally the board I am taking my Computing AS level in) are removing C, C# and PHP from their exam syllabuses, citing low take-up.

In an even more astonishing move, you are still allowed to teach someone programming in Visual Basic 6, a language which has been deprecated in favour of Visual Basic.NET for almost as long as time. Of course, the reason for this may be that many schools can’t afford new computers capable of running Visual Studio in a sandboxed environment, but still—seriously? Why can teachers not simply learn something new like Python or Delphi?

This is not setting a good precedent, especially considering the usefulness of C and the increasing desirability of C#.

May 12, 2010 | 4 comments

Building a programming project, especially a very big project, takes a long time, especially on older computers. This is because many files have to be compiled, linked and built. However, Mac OS X allows a way around this using Distributed Builds.

Distributed Builds distributes the workload across any Mac on your network that has opted in, speeding up the process significantly. This is a form of node computing, which operates almost all modern supercomputers. Distributed Builds divide the workload using the Bonjour protocol, using code that is based on Xgrid, which is Mac OS X’s grid computing system (used in System X, a supercomputer at Virginia Tech constructed entirely of Power Mac G5s originally, and now Xserve G5s). Even a little bit of added computing power will improve things drastically.

There are several prerequisites to this. Firstly, the other computers must be Macs running OS X. They must also have an equivalent or higher version of both OS X and Xcode as the ones installed as your main development machine. I’ll go into this in the instructions.

Firstly, however, you must have a suitable environment. You can carry out the build directly over the network, without any fuss whatsoever. It is a ridiculously simple process. If you have a Mac which doesn’t have AirPort which needs it, and is lying around doing nothing, then you can connect it using a relatively cheap Ethernet switch to a Mac which does have AirPort. You can then share the wireless and Internet connection over this subnet. For example, I have a spare Power Mac G3, which I’ve attached to Welchman, my iMac DV, in the following arrangement.

So, with that sorted, it’s important to check the prerequisites for doing a distributed build. In this event, both my machines are running Mac OS X Tiger, but I could also add a Leopard computer if I so wished.

Now, let’s go about setting the damn thing up.

  1. Install Xcode on all machines that don’t already have it installed. Xcode is Mac OS X’s excellent IDE. It can be found on your OS X CD, or can be downloaded from developer.apple.com. It can take up quite a bit of space, but if you don’t install the documentation (this can all be accessed online) it reduces the amount of space needed drastically. If you downloaded the disk image, you can also save some space by ejecting and then Trashing this afterwards.
  2. Open Xcode. By default, it is installed under /Developer/Applications. You might find it useful to drag it onto the Dock to work with later.
  3. On the main development machine, open Xcode preferences (Command-,). Go to the Distributed Builds tab, and check the ‘Distribute builds to…’ switch. Activate the ‘Share my computer with low priority’ switch: you may need to authenticate to do this.
  4. On your other machines, open Xcode preferences, and go to the distributed build tab. Authenticate, and tick the ‘share my computer’ box(es). Everything is now set up.
  5. When you next build your Xcode project, the build will be distributed across the machines you have enabled to have the build distributed to.
It really is a cinch. You might have to allow it through the OS X firewall (it is a predefined option), and you might (if you have no DHCP server) have to assign IP addresses manually, but these are in rare cases. Otherwise, you should be just fine and ready to go. And, believe me, it really speeds up the build process.

Tags: , , ,