| -- https://haskell.fpcomplete.com/user/DanBurton/20-intermediate-exercises | |
| -- Originally from http://blog.tmorris.net/posts/20-intermediate-haskell-exercises/ | |
| class Fluffy f where | |
| furry :: (a -> b) -> f a -> f b | |
| -- Exercise 1 | |
| -- Relative Difficulty: 1 | |
| instance Fluffy [] where | |
| furry = fmap |
| # Mac OS X Lion introduced a new, iOS-like context menu when you press and hold a key | |
| # that enables you to choose a character from a menu of options. If you are on Lion | |
| # try it by pressing and holding down 'e' in any app that uses the default NSTextField | |
| # for input. | |
| # | |
| # It's a nice feature and continues the blending of Mac OS X and iOS features. However, | |
| # it's a nightmare to deal with in Sublime Text if you're running Vintage (Vim) mode, | |
| # as it means you cannot press and hold h/j/k/l to move through your file. You have | |
| # to repeatedly press the keys to navigate. |
If you are seeing Mongo soft rlimits warnings in your logs, or a WARNING: soft rlimits too low. Number of files is 256, should be at least 1000 when you login to mongo shell via mongo from the commandline, or any mysterious/unexplained mongo connection errors... follow this how-to exactly and it will resolve the issue for you.
(Source of this how to found at basho/basho_docs#1402)
First file:
sudo vi /Library/LaunchDaemons/limit.maxfiles.plist
...containing:
This note tries to document the output of PrintCompilation flag in HotSpot VM. It was originally intended to be a reply to a blog post on PrintCompilation from Stephen Colebourne. It's kind of grown too big to fit as a reply, so I'm putting it here.
Written by: Kris Mok [email protected]
Most of the contents in this note are based on my reading of HotSpot source code from OpenJDK and experimenting with the VM flags; otheres come from HotSpot mailing lists and other reading materials listed in the "References" section.
This
I was talking to a coworker recently about general techniques that almost always form the core of any effort to write very fast, down-to-the-metal hot path code on the JVM, and they pointed out that there really isn't a particularly good place to go for this information. It occurred to me that, really, I had more or less picked up all of it by word of mouth and experience, and there just aren't any good reference sources on the topic. So… here's my word of mouth.
This is by no means a comprehensive gist. It's also important to understand that the techniques that I outline in here are not 100% absolute either. Performance on the JVM is an incredibly complicated subject, and while there are rules that almost always hold true, the "almost" remains very salient. Also, for many or even most applications, there will be other techniques that I'm not mentioning which will have a greater impact. JMH, Java Flight Recorder, and a good profiler are your very best friend! Mea
In the wake of the virus that-must-not-be-named (which most people misname anyway), it seems like everyone and their cat has posted some sort of opinion or how-to on making remote work, work. This is a good thing! Working remotely, particularly full-time, is hard! I've done it for my entire career (aside from an odd 14 month office period in the middle that we shall not speak of), but more relevantly, for the past two years I've been responsible for building, managing, and enabling an entirely remote team, distributed across nine timezones. Remote teams don't just happen by installing Slack and telling everyone to work on their couch: they require a lot of effort to do correctly and efficiently. But, done right, it can be a massive multiplier on your team efficiency and flexibility.
Here's how we do it. I'm going to attempt to structure this post more towards management than engineering, and so I apologize in advance if I assume terminology or knowledge which
tl;dr Generate a GPG key pair (exercising appropriate paranoia). Send it to key servers. Create a Keybase account with the public part of that key. Use your keypair to sign git tags and SBT artifacts.
GPG is probably one of the least understood day-to-day pieces of software in the modern developer's toolshed. It's certainly the least understood of the important pieces of software (literally no one cares that you can't remember grep's regex variant), and this is a testament to the mightily terrible user interface it exposes to its otherwise extremely simple functionality. It's almost like cryptographers think that part of the security comes from the fact that bad guys can't figure it out any more than the good guys can.
Anyway, GPG is important for open source in particular because of one specific feature of public/private key cryptography: signing. Any published software should be signed by the developer (or company) who published it. Ideally, consu