Comments for splat operator

Comment on Clone Ubuntu VMs in VirtualBox by Chema Gallego

Chema Gallego — Mon, 31 Dec 2012 13:46:25 +0000

Great !! It works for me :)

Thanks

Comment on Compacting a VMDK (Virtual Machine Disk Format image) by Ryan Finnie

Ryan Finnie — Mon, 26 Nov 2012 00:06:46 +0000

Thanks for the Finnix recommendation! FYI, the next version to be released (107) will include zerofree out of the box: https://bugs.launchpad.net/finnix/+bug/1075921

Comment on Clone Ubuntu VMs in VirtualBox by Prevent Virtual Machines from Saving Network Interface udev Rules | splat operator

Sat, 24 Nov 2012 23:45:52 +0000

[...] and changing its MAC address is that it won’t be able to initialize the network (as seen in a previous post). I found a permanent fix for [...]

Comment on Ruby instance_eval gotcha by David

David — Wed, 21 Nov 2012 21:25:10 +0000

This was immensely helpful. I couldn't figure out what the deal was with my Padrino app prior to reading this. Thanks so much for posting!

Comment on Clone Ubuntu VMs in VirtualBox by force

force — Tue, 13 Nov 2012 19:49:08 +0000

I found a solution for this. See my new post.

Comment on Prevent Virtual Machines from Saving Network Interface udev Rules by Clone Ubuntu VMs in VirtualBox | splat operator

Clone Ubuntu VMs in VirtualBox | splat operator — Tue, 13 Nov 2012 19:48:11 +0000

[...] Update: I found a permanent workaround for the udev ethernet interface problem. See this post. [...]

Comment on Clone Ubuntu VMs in VirtualBox by Jackson Leung

Jackson Leung — Mon, 12 Nov 2012 09:42:48 +0000

Hey! Thanks for this tip. I actually have a VM I've placed into a flash drive that I plan to operate out of. This tip most likely saved my sanity. Now, I just have to figure out how to avoid having to delete the udev each time I close shop :/

Comment on Defining Functions Inline Is Just Fine by Lashell

Lashell — Wed, 18 Jan 2012 15:58:33 +0000

Bookmarked, I love your site! :)

Comment on JavaScript Performance: Iterating over Arrays with Holes by Christian Iversen

Christian Iversen — Sat, 14 Jan 2012 11:27:22 +0000

If you look for a sorted list of integers in a sorted list of integers, you can do that in O(n+m) time, which is O(n) when m is a constant or "always smallish". It's certainly better than O(n^2). Do this simply by sorting each list, and stepping the index of the list with the smaller value. If it's the same value, you've found an element, and you step both indices. This is a very simple algorithm, that is actually very efficient.

I agree though, if you never have more than 100 records(ish), no complex solution will ever beat the simple one, because of the rather large constants involved in setting it up. JavaScript is (thankfully) rarely a langauge for large dataset processing anyway :)

And yes, I completely agree with the main point: the "good enough" solution takes maybe 20% of the time of the "best", so it's vastly better overall.

And yes, a break; (or even just a return) would be appropriate :)

Comment on JavaScript Performance: Iterating over Arrays with Holes by force

force — Fri, 13 Jan 2012 17:44:28 +0000

Very interesting! Thanks for the thorough reply. Addressing point 2, I actually did consider indexing the IDs (they are unique) and using them for lookup. This is an approach that I have used in the past, binary search and all. But then I weighed the complexity and readability against possible performance implications, and I decided not to write it. I should probably have set some more parameters. The jsPerf that I made really only tells us anything about fairly small data sets. For the problem that inspired this blog, I can be certain that we'll never have more than 100 records so that's sort of what I was looking at. The main goal in my jsPerf was to see if skipping a bunch of undefined array elements by doing a simple "if (this)" was negligibly cheap. The novelty for me was the realization that I should use the simplest solution rather than try to optimize the hell out of every part of the application. Of course, I spent more time thinking about it, constructing the jsPerf and writing about it than I saved implementing a lookup solution. But I'll still call it a win since I think I'm getting better at learning when the "good enough" solution is better than the "best" solution.

P.S. You know, I never apply big O. I don't know why. Obviously, I need to retrain myself. :)

P.P.S. I just realized that I don't break the loop when I find the element in the "complex" result, meaning every single lookup is O(n) instead of averaging like O(n/2). Derp.