Félix Saparelli

Note that ; can actually be better for quick use than &&. With &&, the entire command will fail if the directory already exists. With ;, it will warn you, but still cd into it.

I prefer the latter's "cd in X, making it if necessary" behaviour. YMMV.

@matthewbj The performance optimisation is to not use it at all when not doing debugging. This trick is the equivalent of peppering console.log calls in JS: it's highly inefficient but very useful when doing quick checks. If you want a long-term debug log solution, look into proper logging (to file or tty or socket) so you don't mix things in the output.

See:

• http://www.ruby-forum.com/topic/79295
• http://www.ruby-forum.com/topic/3985130
• http://stackoverflow.com/questions/3417521/what-vulnerabilities-are-possible-in-ruby-with-safe-1
• http://www.confreaks.com/videos/713-rubyconf2011-sandboxing-ruby-the-good-the-bad-and-the-fugly
• http://www.rubyflow.com/items/5642-dead-simple-code-sandboxing

My problem with $SAFE is you can't do anything Ruby'esque if $SAFE is too high but the lower settings aren't even close to being secure. You should be able to truly sandbox some Ruby code and let it do its thing using the full power of Ruby while blocking it from doing things like accessing the file system.

As well as a sentence on that gem's readme:

Getting rid of SAFE level 3, and moving everything into the kernel space.

I'm guessing the author has similar reservation about using $SAFE.

Furthermore, $SAFE is really only correctly implemented in MRI, and might disappear after 2.0. jRuby can be sandboxed using either the gem I mention, or (if you want to go one better) using the JVM's security policies. Rubinius doesn't implement $SAFE and (iirc/afaik) never will.

$SAFE is certainly not meant to be used to run untrusted code, it's meant to be used to throw exceptions when code does stuff you don't want it to. I.e. $SAFE is, by design, not secure.

@jisaacks I never said otherwise. In fact, my position on this is that +"" is safer, and that you should consider doing some proper parsing and checking for anything more complicated (what if someone passes nonsense that happens to start with a number? Suddenly: the unexpected happens).

Also see @pickachu's comment for both: a solution that always returns a actual number (0 instead of NaN), and more importantly, browser inconsistency using parseInt().

And if you want more flexibility, mongoose is a good tiny HTTP server.

You don't even need 20 lines of CSS. See http://coderwall.com/p/oo2bqg (and first comment for the pseudo-element version).

@brokenseal Err what? The only two outputs +anything can give me are a number or NaN. Statements like “Avoid X at all costs” are never useful: instead, explain why it should be avoided, and how it can backfire.

On Linux it's typically xclip that's used:

xclip | cat > paste/file
cat copy/file | xclip

Don't use parseInt. Use +:

parseInt("42")   //=> 42
parseInt("023") //=> 19

+"42"  //=> 42
+"023" //=> 23

Ruby has a for statement?! O.o And it's just a sugar over #each? Ah, useless~

I usually develop all my small stuff in master for the initial version because if anyone looks at it then, they'll see something, instead of a blank repo (maybe with a terse README saying “yep, WIP”).

Then once I reach something that works, I have only working, stable code in master, and develop in branches.

This is probably only because I like to push to github often during development, for backup and early feedback purposes.

Well, see, you tell people to read the source… by pointing them exactly at the right parts of the code and of the relevant commits. Thar's awesome! I'm more referring to a) (standard) library code, and b) generic “read the source” comments, made without referencing as you do. It's a behaviour I equate with someone asking for a specific string function and being given http://www.ruby-doc.org/core-1.9.3/String.html as sole answer (it happens more than one would think). It certainly doesn't seem like something you'd do :)

(Also, rdoc/yard are docs –sorry for the pun– and often, great at that. Even though it's not hand-made, but generated from the code. It's ‘almost code,’ but not quite, abstracting away the details and giving just the API, descriptions, synopsii, and maybe even contextual code. It's still much better than just reading the code, raw.)

You're right on the beginner front. I might not have expressed myself correctly, and I might not have been a beginner long enough to experience too much of it. However I believe ‘moving on [from being a beginner] by not being spoon-fed’ is a bit of an departure from the argument. I can honestly say reading the code of a large application never helped me much in becoming better at programming. Reading and trying out snippets, and reading documentation (and specs! Specs are good for you!), and creating my own stuff, that helped tremendously. I mean, code is what we do, if we weren't reading it… :-/

Generally, I both agree and disagree with you. I agree on the pragmatic front but disagree on the idealist one. At least pardon me for being somewhat of an idealist! :)

— Good, self documenting, well written code is an art and is rather rare, especially with very young (hastily written) or quite old (lots of legacy) codebases.

— Beginners (or low-intermediate users) at a language don't want to read library code. Heck! I don't want to read library code just to figure something out. (I make a point of having a quick “read-over” of the code of every library I use, but in my own time, not on the spot.)

— Code often has a particular structure that one needs to be familiar with in order to understand it. Experience makes this easier, yes (Ruby gems, Rails applications, Python packages, Django installations… all have a general structure, for example), but there's still a lot left to the original programmer. (I have always longed for “code maps” for some large projects, that would essentially show the big picture with annotations of the type “this feature is implemented here and here, and all this code is for BlaBla compatibility, etc,” but I'm getting sidetracked.)

— Finally, code history also has a tendency to make it hard to figure out what code is for. A particular detail might have been put there for a particular edge case, but without context (such as is the case when one is told to “read the code”) it becomes easy to miss.

Good documentation is hard. Good code is hard. Good self-documenting code is extra hard. And generally, it's not the well-designed, well-written methods one will have a problem with. It'll often be with those ‘fuck-you’s of methods. Which is why saying RTFC is so different from saying RTFM.

That's funny, I swear I saw this before on this site. Oh wait, I even did a version of it myself. Glad to know other people are using it.

That's not completely true. $().bind also keeps a list of all events and handlers attached to an element, and does various other little tidbits, such as passing a normalized event object. Knowing that addEventListener is the pure-DOM version of $().bind is half the battle: the various differences between them are what is really interesting.

Is there a Meld-grade integrated diffing tool in this? Merging changes is just about the only hard thing about command-line git, and that's what keeping me from using tools like Git Tower and the like.

Modified for zsh:

grep git ~/.histfile | awk '{CMD[$2]++;count++;}END { for (a in CMD)print CMD[a] " " CMD[a]/count*100 "% " a;}' | grep -v "./" | column -c3 -s " " -t | sort -nr | nl |  head -n10

And my results: (co is checkout, ls is status)

 1  135  32.2196%   commit
 2  36   8.59189%   add
 3  21   5.01193%   co
 4  19   4.53461%   push
 5  18   4.29594%   rm
 6  18   4.29594%   clone
 7  11   2.6253%    ls
 8  10   2.38663%   rebase
 9  7    1.67064%   reset
10  7    1.67064%   pull

Perhaps you meant:

(Math.random()+ +new Date).toString(36).replace('.','')

In Linux, it's called xclip. And pbcopy doesn't work through tmux unless you

brew install reattach-to-user-namespace

and add

set-option -g default-command "reattach-to-user-namespace -l zsh" # or bash

to your ~/.tmux.conf.

+1, but... How is that not secure?

Just a few things:

The speed difference between $() and native DOM queries (getElementById, getElementsByClassName, querySelector(All)...) is incredible. Sizzle has more features. You might also plug in a different, faster, engine. That's not the point.

Mobile performance is incidental. Not everyone is using top-of-the-line Macbook Pros (I used to dev on an old laptop that was slower than my phone). Speed is good no matter what processor is running it; a faster application will often “feel” better.

Doing $(document.getElementById("thing")) is 4x faster than $("#thing") for the exact same result. (/re @clawfire, @gavinblair)

Better code design (i.e. learning to implement less wasteful code) trumps minor this-function-is-faster details. That's what I mean by premature optimisation. (/re @somethingon)

Pure JS doesn't always beat frameworks. In fact, mobile-oriented frameworks will often be more optimised than your own code. (/re @james2doyle)

I'd call premature optimisation on that one. By the time the difference in performance between jQuery and pure DOM becomes important, ditching the library altogether and replacing it with lighter alternatives should be the more logical solution.

It just treats it as text. I imagine one could hook up .data()'s internals to use another decoder, which might be neat in some cases (maybe convert space/comma-delimited list into an array?).

Ah, dreaded compatibility. Let us first refer to lovely caniuse: font-face is supported on all browsers (going back to IE4!) except for Android 2.1 (of which I'd hope there would be no or little remnants) and Opera Mini (obviously). Furthermore, the table notes that IE8 and below only support EOT. So far, so good, as these are quite well known and thoroughly covered already.

This NiceWebType article from back in 2009 indicates that style linking (which is what I'm showing) will not work in IE (and the odd unfixed Opera 10). But what version of IE is that? Simple research would seem to indicate IE8. Further than that, the MSDN documentation is clear: both format hinting and style linking are supported starting from IE9 only.

So it all comes down to what browsers you support. Coderwall, being targeted at developers (read: people who generally should have up-to-date software), should probably be OK (after all, they use box-shadow and border-radius pretty liberally, none of which are supported in IE8). YMMV. Personally, I have been using style linking for all my font needs for as long as I can remember.

And, just a quick thought: if you “reverse” your font-face rules such that the regular one is last, IE8‒ should use that, and apply “fake” styling and weighting. Should be tested first, but in all logic... 😉

@bashir Awesome! :3

Everything just worked peachy. In between 1.6.7.2 and 1.7.0.RC2, something changed and rubygems can't be accessed from within anymore. Or something. I need to redo my testing here.

Hence my caveat above. I understand the positioning. I understand the problem. I also understand how you're proposing to solution it. I was just pointing out that if the screen/window can be kept wide enough, the problem doesn't appear (and at-media blocks can mitigate it). This can all get very complex, though.

Regarding upcoming CSS, I think two solutions to the problem are coming up: alternative layouts (flex, grid) and scoping. With scoping one could, as I understand it, work with hybrid positioning much more easily.

I understand better now, but:

nav {
  position-x: static;
  position-y: fixed;
  top: 150px;
}

will, in my mind's eye, behave exactly as:

nav {
  position: fixed;
  top: 150px;
}

as long as there's no sideways scrolling (which is rare).

Re: the original problem, I thought that W3C was working on something to solution that, but I can't seem to find it.

Ack.

Or, you know, use this:

$('selector').get(0).outerHTML

which is supported in modern browsers (IE included).

When scrolling down, the user should maintain access to the navigation.

---

The problem here is that this is executed as the resize takes place

---

What? Why are you talking about scrolling and then doing stuff with resizing? And the css seems indicate vertical change while your js changes the horizontal... it sounds like you mixed up two different things. Care to clarify?

@engineergio If you want compact, the OP's is as terse as it gets:

var i,c=0;for(i in anArray){c++;}

Or just, err, you know, use ack.

$ ack --php "print_r"

@idered No no no... you can center anything too. I'm just using the body element as a container. Replace body:before with parentelement:before and everything still just works (see: http://jsbin.com/oxuyop/144/edit). After all, it uses the exact same technique... just without extra markup.

Additional scenarios:

"Oh no! I forgot that file."

git add file
git commit --amend -m "blah"

"Oh no! I forgot that file... but the message's good."

git add file
git commit --amend -C HEAD

"Oh no! I forgot one last edit before committing everything."

$EDITOR file
git commit --amend -aC HEAD

I use that last one a lot.

You can also put a .gitkeep in, check only that file in the index, then add an entry in the global .gitignore for that entire directory. Works just as well— both techniques have different advantages.

And given we're not supporting IE7 (don't know about IE8, either, though, but should work)... here's the obligatory no-extra-markup version: http://jsbin.com/oxuyop/102/edit

You're not actually using Sinatra... just Rack. And in any case, a static site doesn't need Rack, Sinatra, Rails, or any other framework: it's static, so just use a plain ol' web server.

Of course, that'll only work if the resources are indeed available using whatever protocol the page was loaded with. As long as you're aware of that, all is good; as soon as you forget it, you start wondering what the hell is wrong with your site.

Note that this is perfect for Google's CDN — including webfonts — as they just support everything you throw at them.