02/16/2012 11:59pm | 8 Comments
Emacs 24 includes many improvements over 23, but there is one particular addition that makes me run around and go crazy with joy: a built-in package management system, ELPA (Emacs 24 is still in development, Bozhidar Batsov has a good guide on how to get it set up). I switched over to Emacs almost a year ago, searching for something that would give me an IDE with the following attributes:
- Functionality (context-based completion, on the fly syntax checking)
- Customization (key bindings, easily extensible)
- Portability (minimal setup on new environments)
There are a lot of nice extensions that do well for the first two. However, Portability was always tricky. To get some of the more power coding features in Emacs, one needed to install large packages, and there was no way to move these around short of zipping the whole thing up or finding and installing all these packages again.
ELPA completes the trifecta I have been looking for. It was now easy to have a list of packages to install. I have a GitHub repository to contain all of my .emacs setup, so I can just clone a repository with every new environment. To make the setup completely automatic, I needed a method to automatically install packages that did not exist. After a little research, I was able to figure it out:
;; Packages to install first (check if emacs is 24 or higher)
(if (>= emacs-major-version 24)
(progn
;; Add a larger package list
(setq package-archives '(("ELPA" . "http://tromey.com/elpa/")
("gnu" . "http://elpa.gnu.org/packages/")
("marmalade" . "http://marmalade-repo.org/packages/")))
(package-refresh-contents)
;; Install flymake mode if it doesn't exist, then configure
(when (not (require 'flymake nil t))
(package-install 'flymake))
(global-set-key (kbd "C-; C-f") 'flymake-mode)
;; flymake-cursor
(when (not (require 'flymake-cursor nil t))
(package-install 'flymake-cursor))
;; Install rainbow mode if it doesn't exist, then configure
(when (not (require 'rainbow-mode nil t))
(package-install 'rainbow-mode))
(defun all-css-modes() (css-mode)
(rainbow-mode))
(add-to-list 'auto-mode-alist '("\.css$" . all-css-modes))
)
)
NOTE!!! This must be run after ALL OTHER INITIALIZATIONS are run! You can do this by placing it within a hook:
(add-hook 'after-init-hook '(lambda ()
(load "~/.emacs.loadpackages"))) ;; anything within the lambda will run after everything has initialized.
As you can see, I've put the above logic into a file called ".emacs.loadpackages". This is so I can remove it at easy if I want a more bare environment.
I'd like to talk about this a little bit in detail. The first line ensures that emacs is version 24 or higher:
(if (>= emacs-major-version 24) PACKAGE_STUFF_HERE)
I then add more repositories to the package manager, gnu and Marmalade (the base package is a bit limited, in my opinion)
(setq package-archives '(
("ELPA" . "http://tromey.com/elpa/")
("gnu" . "http://elpa.gnu.org/packages/")
("marmalade" . "http://marmalade-repo.org/packages/")))
This requires a refresh:
(package-refresh-contents)
And then onto the logic to see if a package exists! You can use require to see if a package exists, nullifying the error message it usually return by adding the true statement at the end. For example, this will return true when the package fly-make cursor is not installed:
(not (require 'flymake-cursor nil t))
You can then add this to a complete clause:
(when (not (require 'flymake-cursor nil t))
(package-install 'flymake-cursor))
And you're done!
Issues:
There a couple of things I'm still working on regarding this setup. Although I haven't gotten any environment breaking errors so far, there's not a lot of error checking, so I'm sure it can break if things are not completely right. In addition, this does not work very well for portable programmers, as Emacs will try to initialize ELPA, resulting in an exception due to not being able to contact the server.
Please leave comments and suggestions!
01/26/2012 07:14pm | 2 Comments
As of this posting, Python has been my main programming language for over three years. Although I definitely feel that Python is not a good fit for all programming projects, the speed and efficiency with which I can code in it has made it my go-to language whenever possible.
As such, I've seen a lot of Python code, and have had ample time to think about some of the more nuanced issues regarding coding standards. Here's a few of my pet peeves, and opinions about them:
from module import *
When I first started python, I used this particular import for a lot of things. I'm using so many methods from this module, why not just import the whole thing? It was definitely a pain in the neck fixing those include issues.
Well, time in the industry has made me realize the error of my ways. This isn't just python related, this is related to any programming language. Includes/Import should always be as obvious as possible. The correct import methodology, is to do as such:
from module import w,x,y,z
or, if you want to be even nicer:
import module
module.x()
But what if we're using ten methods from that module? still gotta do it.
What about 20 methods? still gotta do it
What about 100 methods? don't know how there's 100 methods in a single module, but you still gotta do it.
The reasoning is simple: you're providing a very helpful hint that future coders can use to debug your code years from now. That hint is : where the method is actually found.
While you yourself don't save any time off of doing this, you're saving hours of development time for future coders, giving them a roadmap to exactly what your function's stack actually is. Although this can be given by any IDE that has an understanding of the language and it's dependencies, one shouldn't assume that this is so. In my experience, when debugging, I have spent anywhere between a good ten to twenty minutes looking for methods, especially in python files with twenty lines of imports. To know exactly where a particular method or module comes from goes a long way to making one's code maintainable.
For example, suppose I was a programmer who had to debug, and was able to pinpoint the bug to a method that had been previously written, called a_func. The file calling it looks like:
from foo import *
from bar import *
def b_func():
...
a_func()
...
return
Now if I had no knowledge of the modules foo and bar, I would have to look through BOTH foo and bar, and see if either of those had the function a_func. This is only a minor inconvenience if your code only has two of these imports, but the larger a script gets, and the more includes it brings in over the years, could result in one having to look through several files in various locations, to debug one call. Precious time that could have been saved, had the original code just written:
from bar import a_func
Use ternary's, but only where it makes sense
If you're not familiar with tenary operators, I'd suggest acquainting yourself now. After all, ternary operators only exist because the problem they solve is so prevalent in coding everywhere. Specifically, the strict point where you want a variable to be one of two things. In Python, ternary operators are represented differently than other programming languages (the typical ( condition ? do_this_if_true : do_this_if_false ) operation). Python has:
do_this_if_true if condition else do_this_if_false
Ternary's in general have several uses. The big one is providing a default value:
var = (value if value else default_value)
Basically, in any situation where you have:
if this:
just_one_procedure()
else:
just_one_other_procedure()
One should consider using a ternary. You can also nested ternarys, although I wouldn't suggest doing so for more than one level deep. This is especially useful when you have a variable assignment with four different possible outcomes:
x = ( (1 if a else 0) if b
else (2 if c else 3))
To do so with regular if else statements, one would need ten lines of logic. Ternarys are a lesser known function within Python, and it belongs in any programmer's set of tools.
Lessons Learned from the past three years
1/13/2011
Today I signed up for a new contract with my webhost, HostMonster, for another three years. To commemorate that fact, I've redesigned yusuketsutsumi.com from scratch. Needless to say, an addition three years worth of experience has served me well. Here's an example of what my old website looked like:
While the new site now:
I've obtained a lot of experience and learned a lot of lessons. I'd like to share a few in this post:
int main(){
int i = 0;
for(i = 0; i < 15; i++)
{
i++;
}
return i;
}
Design should be elegant
When I designed my original website, all my head was filled with was thoughts regarding using the cool gimmicks seen on other websites. Things such as transparency on pages, rounded corners everywhere, and cool background images. As you can probably tell, my new site contains none of that. What I've noticed is that although these components are useful, a website does not need to use any of these to look well designed. It is possible to have a nice looking website, implementing luster only when it is necessary. In addition, fancy designs tend to only sacrifice the user experience, which is the sole purpose of a website.
Don't reinvent the wheel
I'm sure this has been hashed over again and again by others, but some people need to hear this over and over again, and experience it themselves, before it really clicks. This is what happened to me.
I spent a very long time obsessed with the idea that, if I built something myself, it would be way better than anyone else's out there. And the fact is, sometimes this may be true. However, those who think like me, and actually choose do so, are not looking at the whole picture.
Building anything has a much larger requirement that just the expertise to do so. It requires time, and a lot of it. One would have to spend time designing the project, laying out ever single detail of how it works, how it would talk to other services, and finally, how it handles errors. Considering all the factors, it doesn't make a lot of sense to devote so much time to one project, especially when this particular component is just one step from your own full-on service.
Another hidden cost that one doesn't immediately realize is that of maintainability.
After seeing a coworker's presentation completely done using html5 and javascript, I really realized how much of a platform that html5 can be. Effectively, it's a ubiquitous platform by which any operating system can run code, with very little prior setup necessary. I really liked the concept of an html5 slideshow, so I looked around for one that suited my needs. There wasn't one, so I began to write my own. I present Slimy:
http://code.google.com/p/slimy/
You can see an example here:
http://slimy.googlecode.com/git/example.html
I explored html5 slideshows quite a bit, and I had two main issues that got me interested in writing my own: