mifrai

Some thoughts and responses to what you've said:

1. I try to make sure anything I enter into my notes are intended to last, filtering/processing is a key step to that. This often means I won't enter notes unless they can contribute to my understanding of some lasting higher level concept. For example, I don't have any notes on tech library X, Y, Z. But I do have notes on concepts, like "Required accidental complexity should be avoided or separated" and if a library Z has a unique way of doing so, I may incorporate my understanding of the strategy to further my understanding of the concept.

2. My goal is less to simply collect links/articles, it's to process and assimilate. I write everything in my own words to clarify my understanding. I link it to other topics in my notes to help build stronger associations, which helps me ground and recall the knowledge. I'm also exploring whether I want to put some spaced repetition in with my notes to help keep pieces of information fresh.

3. I treat my notes as separate from my todo lists. The extra bit that these tools give you is the linking and clustering of information. I find the associations useful for encouraging identification/contextualization of where that knowledge sits in my current understanding and, periodically, discovering serendipitous connections.

4. I rarely revisit old books as well, but I also find that my recall of those books are terrible. Part of my note taking is to make sure that I have a better chance of understanding and taking away valuable information from those books. It's also worth mentioning that that I don't aim to have notes on the book, I aim to have new concept notes or updating existing concepts with new information.

So what domains do I find these apps useful? It's unclear to me how much I can attribute to the linking the app encourages. But, I do find myself recalling what I've noted much more frequently in my day to day as an software engineer. The identification and concretization of patterns/concepts has helped me be more articulate and have more clarity in my work, particularly when giving feedback to others.

All that said, everybody is different. This process might not work for you, or you may find you don't need it to get the same effects. I know plenty of successful people that don't. And if it doesn't work for you, I wouldn't worry too much about it.

https://fi.google.com/about/phones/ - 16GB $199 / 32GB $249

Here, you can't just magic into existence or modify an unknown 'a' value.

So, I'm not convinced Dropbox will do anything unless it is a "PR crisis"/publicly handled. They have their own earnings driven goals and I don't think discontinued Team members will blip on that radar. Maybe if it significantly inconveniences Team admins, but that doesn't appear to be the case - admins don't lose their data and it seems like they only have to click a button.

However, I'm not saying that this is an issue that should have been publicly addressed. I'm just saying that if it weren't, I wouldn't expect much action to be done on it.

[Votebox]: https://www.dropbox.com/votebox/all#votebox:popular:0

    filterM' f xs = map fst . filter snd . zip xs <$> mapM f xs

    nexist n xs = take n <$> filterM (fmap not . doesFileExist) xs

Be careful here. Because you're in the IO monad, the entire list of files will always be computed first (ie. doesFileExist will be called for every file given).

Non-strict doesn't really buy you much here. The "expensive" operation here will always be executed. At most, you're avoiding converting some list-consing-thunks to a list.

But there's a very real and somewhat irrational negative emotional response when going from free to not-free. Or alternatively, from included in private costs to a paid for feature taken away.

Bad for me as now I have to find another service to store my project binaries and (likely) add to my monthly bills.

There are two things that compiled Heist loses: the ability to bind new splices on the fly at runtime and splice recursion/composability.

I haven't checked or read the doc thoroughly, but if it's what I think it means - all we get is hierarchal splices. Which is still a lot, but it's not quite as magical.

[1]: http://snapframework.com/docs/tutorials/compiled-splices

  notes = cycle ["c", "c#", "d", "d#", "e", "f", "f#", "g", "g#", "a", "a#", "b"]
  majorSteps = [2, 2, 1, 2, 2, 2] :: [Int]

  scale note = map (dropWhile (/= note) notes !!) . scanl (+) 0

  scale note = map head . scanl (flip drop) (dropWhile (/= note) notes)

  λ> scale "d" majorSteps
  ["d","e","f#","g","a","b","c#"]

As mentioned by gokfar, I really look forward to the ergodox group buy

[1] http://www.haskell.org/ghc/docs/latest/html/users_guide/sepa...

Some use this to say TDD - which has ties to agile - doesn't work. But most people conclude that TDD isn't a silver bullet and you have to know about your problem domain before diving in.

Here's someone elses' blog post which includes links to both sets of posts: http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-s...

Hard decisions are difficult things to do with a stress-shot mind. Particularly when it's so easily framed as "admitting defeat"

I think this argument is slightly different than just saying 5 people is enough for any sort of study. I still would have liked to seen more people. Or at least additional studies with modifications to inspect or confirm specific aspects of their findings.

Moral of the story? Don't use PHP for stats.

I suppose it's because I've always been a tinkerer and I love the fact that the wall between editing with emacs and editing emacs is so small.

Anyways, this is all old news. Everybody already knows the arguments for both sides and they're both true. I still use vim when the job fits (configs or quick edits) and I use largely emacs for my development (even if though I work at a vim shop and everybody gives me dirty looks).