Finally someone has got some scripts together to maximise windows in osx.
OSX has this weird idea that you want to see lots of windows at once. "Maximizing" a window therefore means make it big enough to show the content of the window, but not too big. This leaves the application to decide how big is big enough. Some apps do this fine... others (like Preview) keep getting it wrong.
Grab these scripts form git hub. From a terminal type "rake install", then type "rake install_fastscripts" so you can map the scripts to keys easily. Once you have this working map Maximise to something like Ctrl + Apple + M and you can now make one app take over the whole screen.
THANK YOU TopFunky THANK YOU!
A couple of the scripts are hardcoded to use Terminal, so I have forked the repository for my own edification. I also want to fix a problem with the scripts expecting the draws to be on the right hand side of a window.. which it isn't always.
Nigel Thorne's software development blog, focusing on finding simple solutions to real work problems.
Saturday, September 13, 2008
Lisp in Ruby... amazing
http://onestepback.org/index.cgi/Tech/Ruby/LispInRuby.red
You have to check this out if you have any interest in programming languages at all.
You have to check this out if you have any interest in programming languages at all.
Wednesday, August 27, 2008
Make a Bootable USB from a DMG
Here's the simplest process I have seen...
Note: --erase will cause the usb key to be wiped AND is what 'bless'es the device so it becomes bootable.
There you go..
- Mount a bootable DMG image so it appears in /Volumes (eg. /Volumes/SomeAppDisk)
- Mount a USB Key you don't mind erasing (eg. /Volumes/USBToBeWiped ) (should happen just by sticking it in the machine)
- From a terminal type
sudo asr --restore --source /Volumes/SomeAppDisk --target /Volumes/USBToBeWiped --erase
- wait ....10....20....30....40....50....60....70....80....90....100
Note: --erase will cause the usb key to be wiped AND is what 'bless'es the device so it becomes bootable.
There you go..
Running a .NET Executable from a Network Drive
Rob Smyth is developing NUnitGridRunner, a tool to run nunit.console on several machines at once.
As any application under test grows, so does the number of UATs. Rob's project aims to allow us to scale the running of UATs by adding network boxes.
What does this have to do with Running .NET executables on network drives?
Well, Rob needs to distribute the latest version of the assemblies and tests to each machine so they could run the tests. It's simpler if they just all run from a network path. ,However .NET got in the way.
1/2 a day later we had a solution.
If you run nunit-console.exe from a command shell accessing it from the network drive, you get the following error.
This is due to .NET's permissions system. There are lots of articles online telling you how to recompile your exe to make it run. This is a 3rd party exe though, so I don't want to have to recompile it. That would mean that each time I want to upgrade I would have to do extra steps.
Anyway.. here is the solution I used.
First I changed the Zone that .Net things the network drive belongs to.
Control Panel >> Internet Options >> Security >> Local Intranet >> Click Sites... >> Advanced...
in 'Add this Web site to the zone:' enter the network path.. and click Add
eg. \\MyNetworkMachine\DirectoryContainingExe
You can test this worked by running the executable again from a dos prompt...
Notice it moved to Intranet.
Now all you have to do is tell .NET to trust executables in that zone.
Control Panel >> Administrative Tools >> .NET Framework 2.0 Configuration >> Configure Code Access Security Policy >> Adjust Zone Security >> Next >>
Click "Local Intranet" and slide the slider up to Full. Then click Next a couple to of times.
You can now run the executable... TADA!
What you've done is allow .NET assemblies in the local intranet to be executable on your machines. If this represents a security risk for your machines then this is not the right solution for you.
For us it works great.
As any application under test grows, so does the number of UATs. Rob's project aims to allow us to scale the running of UATs by adding network boxes.
What does this have to do with Running .NET executables on network drives?
Well, Rob needs to distribute the latest version of the assemblies and tests to each machine so they could run the tests. It's simpler if they just all run from a network path. ,However .NET got in the way.
1/2 a day later we had a solution.
If you run nunit-console.exe from a command shell accessing it from the network drive, you get the following error.
Unhandled Exception: System.Security.SecurityException: That assembly does not allow partially trusted callers.
at System.Security.CodeAccessSecurityEngine.ThrowSecurityException(Assembly asm, PermissionSet granted, PermissionSet refused, Runti
ityAction action, Object demand, IPermission permThatFailed)
at NUnit.ConsoleRunner.Class1.Main(String[] args)
The action that failed was:
LinkDemand
The assembly or AppDomain that failed was:
nunit-console, Version=2.4.6.0, Culture=neutral, PublicKeyToken=null
The method that caused the failure was:
Int32 Main(System.String[])
The Zone of the assembly that failed was:
Internet
The Url of the assembly that failed was:
file://aumelw021202/GridRunnerSandPit/AUMELW061120/nunit-console.exe
This is due to .NET's permissions system. There are lots of articles online telling you how to recompile your exe to make it run. This is a 3rd party exe though, so I don't want to have to recompile it. That would mean that each time I want to upgrade I would have to do extra steps.
Anyway.. here is the solution I used.
First I changed the Zone that .Net things the network drive belongs to.
Control Panel >> Internet Options >> Security >> Local Intranet >> Click Sites... >> Advanced...
in 'Add this Web site to the zone:' enter the network path.. and click Add
eg. \\MyNetworkMachine\DirectoryContainingExe
You can test this worked by running the executable again from a dos prompt...
The Zone of the assembly that failed was:
Intranet
Notice it moved to Intranet.
Now all you have to do is tell .NET to trust executables in that zone.
Control Panel >> Administrative Tools >> .NET Framework 2.0 Configuration >> Configure Code Access Security Policy >> Adjust Zone Security >> Next >>
Click "Local Intranet" and slide the slider up to Full. Then click Next a couple to of times.
You can now run the executable... TADA!
What you've done is allow .NET assemblies in the local intranet to be executable on your machines. If this represents a security risk for your machines then this is not the right solution for you.
For us it works great.
Sunday, August 24, 2008
Design Patterns in Ruby
Neal Ford gave a great talk at erubycon about the use of Design Patterns in ruby.
I really liked a couple of tips on how to use interfaces as named groups of methods and mixin's for states.
I really liked a couple of tips on how to use interfaces as named groups of methods and mixin's for states.
Subscribe to:
Posts (Atom)