636 karma · joined March 20, 2008
CodeCity [1]. A city represents a code base. Each class is represented as a building. The aspect of a building gives information on the corresponding class. For example: the color is the number of lines, the height is the number of methods and the width is the number of attributes.
System Complexity View and Class Blueprint [2]. Like CodeCity the color and shape represent various attributes. An added benefit compared to the codecity is that you can also show links between the code elements. For example inheritance or invocation.
NDepend [3] for .NET also has many interesting code diagrams.
[1] http://www.inf.usi.ch/phd/wettel/codecity.html
Us humans just don't do well with edge cases in ranges/bounds. Another seemingly simple task which is easy to trip over is : determining if a time interval overlaps another.
I started a comment but it became gargantuan so I turned it into a blog post : http://tburette.github.io/blog/2014/06/25/the-power-of-keepi...
Speaking of search, I wish there were a brew search on the project description instead of just the name of the project.
Doesn't mean it is a good idea though.
Mother obesity affects The brain and metabolism of the baby. This includes the way fat is managed. This is even before birth.
- primitives
- a way to combine primitives
Combining instructions together (and giving it a name) is just a function. This is nothing extraordinary for us programmers. However exposing that ability to users of a program for extensibility is rarely done, Yet it yields immense power for little complexity from the user comprehension standpoint.
The homepage does a poor job of convincing me to install the application : an image (carousels don't count) and two lines of text for a visual application.
It would be awesome if someone made a table with CSV features in one dimension and application/library behaviour in the other.
I tried some memorizing techniques. It's a great feeling to improve 10x at a (specific) memorizing tasks in very little and effort time by using one weird trick©.
I used to try to remember random words during my commute and recall them when coming back. I took a list of random words from /usr/dict and set myself a timer of a few minutes to remember 30 words using memory palace. I used various places from the commute itself to store words. It was fun to see the words pop-up automatically in specific places on my way back. My performance declined after a while because I wasn't able to erase the previous words.
What's so great about Lisp? : its extreme malleability in the way you write code and the data it uses.
Code and data are the exact same things in lisp. They are represented the same way : lists represented with braces around them who can be nested. It's called s-expressions and they are in the form (<operator> <operand1> <operand2> <operand3>). There is no fundamental difference between code and data they are just list represented as s-expressions:
(list 1 (list 2 3))
(+ 1 (+ 2 3))
(task
(time 14 00)
(log "beginning of task")
(job (backup-files (important-files-in (list-files))))
(job (delete (list-files))))
The one nice thing about s-expressions (sexp) instead of classical curly braces is that the code written in sexp IS ITSELF the abstract syntax tree of that code.
For example, think of a function function add(a, b){return a+b;}
You could convert this function into its syntax tree like this :
(define-function (name add) (parameters a b)
(body (return (+ a b))))
(defun add (a b)
(+ a b))
The syntax of Lisp is the same as its internal represention. That's called homoiconicity.
What's so great about that? Well, mix that with macros whose language is Lisp itself and can do anything with s-expressions and you end up wielding great powers.
A simple example. Let's go back to our task example. We can treat it as data :
//not actual lisp code but you get the point
var my-task = (task
(time 14 00)
(log "beginning of" )
(job (backup-files (important-files-in (list-files))))
(job (delete (list-files))))
//not actual lisp code
(defun time (hour minutes) (print "%d:%d" hour minutes))
(defun log (string) (print string))
//we say that task is a function
//that should call each list it contains as a function
(defun task () /*execute each list it contains*/)
//...
(my-task)
Now for the last touch : add to Lisp a powerful macro system that can take any s-expression (any list) and transform it any way it see fits and you end up yielding great power. What's that language? It's Lisp itself. Code is data. Lisp code evaluting other lisp code. I am so enlightened.
Not enlightened? Didn't get anything out of my post? Then give Lisp a try! You have to dive into Lisp to be able to get it. As Eric raymond put it : "Lisp is worth learning for the profound enlightenment experience you will have when you finally get it; that experience will make you a better programmer for the rest of your days, even if you never actually use Lisp itself a lot." - ESR
You tell the banquet manager of the hotel you are considering that the morning breakfast must include a large glass of freshly squeezed orange juice for everyone of the attendees. It must be squeezed no more than two hours before the breakfast.
It is not possible to do so. Squeezing that much orange in much a short amount of time would be prohibitively expensive.
If the manager says yes he is either lying or incompetent and you'd better find someone else who will tell you it's not possible.
GUI emacs does brings nice features: -multiple fonts / font sizes at the same time (nice for minimap http://www.emacswiki.org/emacs/MiniMap !) -more shortcut possibilities with s- added to the usual C- and M-- -more colours
Shell/ansi-term modes don't work well enough. There's always problems with shortcuts/encoding/escape sequences/Ncurse.
Also with some work you can synchronize the OSX clipboard with tmux's one.
I've been investing some time in the command line on my Mac. I am moving from a dilettante going to the shell on a per-need basis to a more seasoned terminal native. It pays off handesomely! It's hard to convey how nice it to have to have a keyboard-based unified environment instead of a series of disjoined mouse-based GUI experiences.
Here are some recommendations pertaining to mastering the command line on a Mac specifically:
-You can make the terminal start instantaneously instead of it taking several seconds. Remove the .asl files in /private/var/log/asl/. Also remove the file /users/<username>/Library/Preferences/com.apple.terminal.plist
- Install iterm2. It possesses many fancy features but honestly I hardly ever use them. The main reason to use it instead of the default Terminal application is that It just works©.
-Make your terminal look gorgeous. It may sound superficial but it actually is important when you spend expanded period of time in the terminal. You go from this http://i.imgur.com/cx3zZL8.png to this http://i.imgur.com/MQbx8yK.png . You become eager to go to your terminal instead of reluctant. Pick a nice color scheme https://code.google.com/p/iterm2/wiki/ColorGallery . Use a nice font (Monaco, Source Code Pro, Inconsolata are popular). Make it anti aliased.
-Go fullscreen. Not so much for the real estate but for the mental switch. Fullscreen mode is a way to immerse yourself into your productive development world. No browser, no mail, no application notification. Only code.
-Install Alfred. It's the command line for the GUI/Apple part of your system. Since I installed it I stopped using the dock and Spotlight. Press ⌘+space then type what you want and it comes up. In just a few keystrokes you can open an application, open gmail/twitter/imdb/..., make a webs search, find a file (by name, by text content), open a directory,... It's difficult to describe how empowering it is to being able to go from 'I want to check something out in the directory x which is somewhere deep deep in my dev folders' to having it displayed in 2 seconds flat.
-Make a few symlinks from your home directory to the directories you use frequently. Instead of doing cd this/that/code/python/project/ you just do cd ~/project.
-Learn the shell. I recommend the (free) book The Linux Command Line: http://linuxcommand.org/tlcl.php . It guides you gently from simple directory navigation all the way up to shell scripting.
-Use tmux. Essential if you want to spend some time in the terminal. You can split the window in multiple independent panes. Your screen will have multiple terminals displayed simultaneously that you can edit independently. For example I'll have the code in one side and on the other side a REPL or a browser. You can also have multiple windows each with its own set of panes and switch from on to the other. With the multiple windows I can switch from one aspect of a project to another instantly. E.g: one window for the front-end dev, a second one for the backend and another for misc file management/git/whatever.
-Pick an editor and work towards mastery. I don't care if you choose vi or emacs. You'll be surprised how simple features can make a big change in how you type. You'll be even more surprised at how good it feels
The terminal is here to stay. It's a skill that bears a lot of fruits and that deprecate slowly. The more you sow the more you reap.
In The Nature of the Firm [1] Ronald Coase wondered why companies didn't contract out instead of having employees and why indeed firms exist in the first place instead of using the movie industry system.
His answer was that there are transaction costs associated to using the market. There are also other costs such as search/informgation, bargaining, trade secrets,.. The costs of going to the market makes it less attractive. He got the Nobel Prize for that.
Internet lowers that cost and makes it possible where it was impossible before. It's definitely a new opportunity companies don't exploit.
Kaggle [2] does it for predictive modelling.
[1] https://en.wikipedia.org/wiki/The_Nature_of_the_Firm [2] http://www.kaggle.com/competitions