Showing posts with label Programming Talk. Show all posts
Showing posts with label Programming Talk. Show all posts

Monday, July 4, 2011

What every programmer should know about time

SkyHi @ Monday, July 04, 2011
Some notes about time:

UTC: The time at zero degrees longitude (the Prime Meridian) is called Universal Coordinated Time (UTC).
GMT: UTC used to be called Greenwich Mean Time (GMT) because the Prime Meridian was (arbitrarily) chosen to pass through the Royal Observatory in Greenwich.
Other timezones can be written as an offset from UTC. Australian Eastern Standard Time is UTC+1000. e.g. 10:00 UTC is 20:00 EST on the same day.
Daylight saving does not affect UTC. It's just a polity deciding to change its timezone (offset from UTC). For example, GMT is still used: it's the British national timezone in winter. In summer it becomes BST.
Leap seconds: By international convention, UTC (which is an arbitrary human invention) is kept within 0.9 seconds of physical reality (UT1, which is a measure of solar time) by introducing a "leap second" in the last minute of the UTC year, or in the last minute of June.
Leap seconds don't have to be announced much more than six months before they happen. This is a problem if you need second-accurate planning beyond six months.
Unix time: Measured as the number of seconds since epoch (the beginning of 1970 in UTC). Unix time is not affected by time zones or daylight saving.
According to POSIX.1, Unix time is supposed to handle a leap second by replaying the previous second. e.g.:

59.00
59.25
59.50
59.75
59.00 ← replay
59.25
59.50
59.75
00.00 ← increment
00.25

This is a trade-off: you can't represent a leap second, and your time is guaranteed to go backwards. On the other hand, every day is exactly 86,400 seconds long, and you don't need a table of all previous and future leap seconds in order to format Unix time as human-preferred hours-minutes-seconds.
ntpd is supposed to make the replay happen after it sees the "leap bits" from upstream timeservers, but I've also seen it do nothing: the system goes one second into the future, then slowly slews back to the correct time.

What every programmer should know about time:

Timezones are a presentation-layer problem!
Most of your code shouldn't be dealing with timezones or local time, it should be passing Unix time around.
When measuring time, measure Unix time. It's UTC. It's easy to obtain. It doesn't have timezone offsets or daylight saving (or leap seconds).
When storing time, store Unix time. It's a single number.
If you want to store a humanly-readable time (e.g. logs), consider storing it along with Unix time, not instead of Unix time.
When displaying time, always include the timezone offset. A time format without an offset is useless.
The system clock is inaccurate.
You're on a network? Every other system's clock is differently inaccurate.
The system clock can, and will, jump backwards and forwards in time due to things outside of your control. Your program should be designed to survive this.
The number of [clock] seconds per [real] second is both inaccurate and variable. It mostly varies with temperature.
Don't blindly use gettimeofday(). If you need a monotonic (always increasing) clock, have a look at clock_gettime().
ntpd can change the system time in two ways:
Step: making the clock jump backwards or forwards to the correct time instantaneously.
Slew: changing the frequency of the clock so that it slowly drifts toward the correct time.
Slew is preferred because it's less disruptive, but it's only useful for correcting small offsets.

Special mentions:

Time passes at a rate of one second per second for every observer. The frequency of a remote clock relative to an observer is affected by velocity and gravity. The clocks inside GPS satellites are adjusted for relativistic effects.
MySQL (at least 4.x and 5.x) stores DATETIME columns as a "YYYY-MM-DD HH:MM:SS" string. I'm not even kidding. If you care at all about storing timestamps, store them as integers and use the UNIX_TIMESTAMP() and FROM_UNIXTIME() functions.

REFERENCES
http://unix4lyfe.org/time/

Wednesday, May 25, 2011

Top 10 Programming Fonts

SkyHi @ Wednesday, May 25, 2011
I’m a typeface geek, and when it comes to selecting a font I’ll stare at all day, I tend to be pretty picky. Recently, when I discovered that a friend was using a sub par typeface (too horrible to name here) for his Terminal and coding windows, my jaw dropped, my heart sank a little, and I knew it was due time for me to compose this article.
What follows is a round-up of the top 10 readily-available monospace fonts. Many of these fonts are bundled along with modern operating systems, but most are free for download on the web. A few, notably Consolas, are part of commercial software.

A note about anti-aliasing

In the past, we’ve had to decide between tiny monospace fonts or jagged edges. But today, modern operating systems do a great job of anti-aliasing, making monospace fonts look great at any size. It’s not 1990 anymore. Give your tired eyes a break and bump up that font size.
If you have any doubt that anti-aliased fonts are apropos for code, note that even the venerable BBEdit — which for years has shipped with un-aliased Monaco 9 set as the default — has made the jump. The app now ships with a specially licensed version of the Consolas font from Ascender, bumped up in size, and with anti-aliasing on by default. Panic includes a special anti-aliased font (Panic Sans, which is actually just a version of Deja Vu Sans Mono) with its popular Coda application.
Unless otherwise noted, I’ve used a larger size font, 15-point in fact, for the examples here to illustrate their legibility at larger sizes and with anti-aliasing turned on.

10. Courier

All systems ship with a version of Courier (sometimes Courier New), and unfortunately, many have it set as the default font for terminal and editor windows. It does the job, but it’s a bit dull and boring, lacking style and class. I don’t recommend this font if you have any other choice — and fortunately, you do. If you use this font, please bump the size and turn on anti-aliasing.
Courier New
Figure 1 Courier New

9. Andale Mono

A bit better than the Courier family, Andale Mono is still relegated to the “default font” category as it ships with some systems, and you wouldn’t want to download or use it if it wasn’t already there. The character-spacing is a bit too clumsy and the letters are a bit too wide for my tastes.
Andale Mono
Figure 2 Andale Mono

8. Monaco

Monaco is the default monospace font on the Mac and has been since its inclusion in System 6. It’s a solid, workhorse font that really shines at smaller font sizes with anti-aliasing turned off. I loved this typeface back when my eyes could tolerate staring at a 9-point font for hours, but those days are behind me. This font looks great at 9 or 10-points (Figure 4), and doesn’t look too shabby anti-aliased at higher sizes (Figure 3).
As far as I know, you can only get Monaco as a part of Mac OS, but there are alternatives, so keep reading.
Monaco
Figure 3 Monaco
Monaco 9
Figure 4 Monaco 9-point, without anti-aliasing

7. Profont

Profont is a Monaco-like bitmap font available for Mac, Windows, and Linux (there’s also a modified version for Mac OS X called ProFontX by a different author). They’re best at smaller sizes, and make a great alternative to Monaco if you’re on a non-Mac platform and want really tiny fonts and the eyestrain that goes along with them.
Profont (and ProFontX) is intended for use at 9-points with anti-aliasing turned off.
Profont
Figure 5 Profont 9-point, without anti-aliasing

6. Monofur

Monofur is a unique monospace font that looks great anti-aliased at all sizes. It’s a fun font with a distinct look that is vaguely reminiscent of Sun’s OPEN LOOK window manager, which ran Solaris (aka SunOS) systems back in the late 80’s. If you’re looking for something a bit different, try this font, but make sure you have anti-aliasing turned on, even at small sizes.
Monofur
Figure 6 Monofur

5. Proggy

Proggy is a clean monospace font that seems to be favored by Windows users, although it works fine on a Mac. It’s a clean font intended to be used only at smaller points, and without anti-aliasing.
Proggy Clean
Figure 7 Proggy Clean at 15-point (yes, 15-point), without anti-aliasing

4. Droid Sans Mono

The Droid font family (available for download here) is a nice font family designed for use on the small screens of mobile handsets, like Android, and licensed under the Apache license.
Droid Sans Mono makes for a great programming font. It’s got a bit of flair, and stands out among the other monospace fonts I’ve listed, and its only real flaw is the lack of a slashed zero.
Droid Sans Mono
Figure 8 Droid Sans Mono

3. Deja Vu Sans Mono

The Deja Vu family of fonts are one of my favorite free font families, based on the excellent Vera Font family. The Deja Vu fonts have been updated with a wider range of characters while maintaining a similar look and feel to that of Vera.
This was my go-to font family for many years. It looks great at any size with anti-aliasing turned on.
Panic ships a font with it’s Coda application called “Panic Sans” which is based on this font. Gruber says via email that when he compared Panic Sans against Vera, he noted that “Panic had noticeably crisper punctuation chars” and that it seemed like they had improved the hinting on some characters as well.
Deja Vu Sans Mono
Figure 9 Deja Vu Sans Mono

2. Consolas

Consolas suddenly appeared on my Mac after I installed Microsoft Office, along with a handful of other new fonts from Microsoft.
This font was designed by Luc(as) de Groot for Microsoft’s ClearType font family (there’s a nice write-up with samples of each of the new Microsoft fonts here). Consolas is a commercial font, but is bundled with many Microsoft products, so there’s a good chance you might already have it on your system.
You’ll absolutely want to have anti-aliasing turned on if you’re using Consolas, because it’ll look terrible without it.
Too bad it’s not free … if it was, it would be #1 on this list.
Consolas
Figure 10 Consolas

1. Inconsolata

Inconsolata is my favorite monospaced font, and it’s free. Shortly after discovering it, it quickly supplanted Deja Vu Sans Mono as my go-to programming font. I use it everywhere, from Terminal windows to code editors. It has a certain sublime style that’s unique without being over the top, and it looks fantastic at both large and small sizes. I use this font when I show code samples in a presentation, and it’s the font we use in Terminal and TextMate windows when filming PeepCode screencasts.
Inconsolata is designed to be used with anti-aliasing enabled, but it’s surprisingly legible even at very small sizes. A big thanks to Raph Levien for creating this font, and for making it free.
Inconsolata
Figure 11 Inconsolata

Thoughts?

Did I miss your favorite coding typeface? Think the list is out of order? Let me know. If there’s a typeface you think should be in this list, please let me know in the comments section below. If it meets my ridiculous standards, I’ll review it and include it in a follow-up article.


REFERENCES
http://hivelogic.com/articles/top-10-programming-fonts/

Thursday, September 16, 2010

Bytecode, Opcodes, Dalvik, Java, Virtual Machine(VM)

SkyHi @ Thursday, September 16, 2010
I asked an Android guy to explain some things to me about Dalvik, so I could understand the Oracle v. Google situation in more depth.
I'm not a programmer, I told him, but I need to understand the tech behind the lawsuit, so I can understand when the lawyers start arguing about what Google did and didn't do and whether it was entitled to do it or not. What is Dalvik? Why use it? So I asked Mark Murphy, the founder of CommonsWare, and who is the author of three books on Android application development, including Busy Coder’s Guide to Android Development, to explain it. He also trains folks in developing for Android. Also, he doesn't work for Google, so he can speak more freely. Once you are in litigation, most companies are silent as the grave until it's decided. Don't go by SCO. That big-mouth grandstanding to the media was not typical.
If, like me, you never paid much attention before to all the intricacies of Java, it's a chance to get up to speed on all that, as the article walks us through different ways the word Java is used, sometimes a bit loosely, as well as explaining what Dalvik does and the benefits it offers.

What I understand is that there were important technical reasons why Google would want to roll their own code, involving security, memory consumption, and speed, quite aside from any legal or licensing issues.
This article isn't directly about the legal issues, by the way, the question that hovers over this matter in my mind, namely can anyone can write their own Java-like code without getting sued? This is just about the technical side, but as the case goes forward, understanding the technical bits will help us to understand the legal bits.
I've learned a few other things from researching and asking around that helped me to further understand the context for why Google went the way it did. For example, Sun's version of Java for mobile, Java ME, is released under GPLv2 only, but unlike OpenJDK, the open-source version of Java SE, there is no Classpath exception applied to Java ME, so using it might create doubt about whether the system exception applied. Moreover, none of the innovation over the past few years (like JavaFX) is in the open source version. I think then that it would be accurate to discern that Google wanted something better than what was available.
So, with that introduction, here's Mark's article:
**************************

What is Dalvik?
~ by Mark Murphy
When it comes to the Oracle lawsuit against Google regarding Android, many sites and news outlets say that “Android applications are written in Java”. As usual, this is a bit of shorthand.
To really understand what is going on, and where Oracle’s lawsuit comes into the picture, we need to have a bit more detailed picture of what really goes on when somebody writes an Android application:
1. Developers write Java‐syntax source code, leveraging class libraries published by the Android project, Apache Harmony, and other groups. 2. Developers compile the source code into Java VM bytecode, using the javac compiler that comes with the Java SDK.
3. Developers translate the Java VM bytecode into Dalvik VM bytecode, which is packaged with other files into a ZIP archive with the .apk extension.
4. An Android device or emulator runs the .apk file, causing the bytecode to be executed by an instance of a Dalvik VM.
And for most of you, that description was gibberish. That’s the reason why we use the shorthand “Android applications are written in Java” — spelling out all those details every time would get very tiresome. But, we need to sort out this gibberish to answer questions like:
What is Oracle suing over?
Why does this impact Google, if Java was released under the GPL?
Who else might be at risk due to Oracle’s decision to sue?
This article will try to explain two things, in lay terms:
1. What does all that gibberish mean? 2. What technical reasons are there for all that gibberish, compared to the similar gibberish an ordinary Java developer would use?
3. Where do the Oracle patents and such tie in, generally speaking?
First, a few disclaimers:
  • In the interests of making this stuff make sense to more ordinary people, I will wind up using some shorthand of my own from time to time. Purists will probably come up with any number of places where what I say glosses over some details. I am certainly interested in making updates and corrections as needed, where those will materially help ordinary people understand things better.
  • I will use “Sun” to refer to the firm that invented Java and created the Java development tools. I will use “Oracle” to refer to the firm that acquired Sun and, therefore, owns patents, copyrights, and trademarks relevant to Java.
  • I am an Android advocate, though I do not work for Google. While this article is not strictly intended to steer readers’ opinions one way or another on the merits of Oracle’s lawsuit, I am sure that my biases will leak through.
  • This article is written for people who have a smattering of technical knowledge, enough to, say, have made some sense over what was going on in the various lawsuits that SCO was recently a part of.
  • I have a somewhat quirky sense of humor. You have been warned.
Explaining the Gibberish Let’s take those four pieces of gibberish and examine them, one scary‐looking phrase at a time.
“Java‐syntax source code”
“Java” itself is a bit of shorthand. There are many things that can legitimately be called “Java”. One of those things is the syntax of the Java programming language.
Software developers write source code, in some programming language. Java offers one such language, but there are a crazy number of other programming languages, from FORTRAN and COBOL of the mid‐20th century to newcomers like Scala and Clojure.
Each programming language has a syntax, just as each human language has its rules of grammar and roster of available words. The Java programming language has a specific syntax.
Most — but not all — Android developers will be creating Android applications by writing Java‐syntax source code, no different than if they were writing Java applets, Java desktop applications, so‐called “Java ME” applications for some mobile phones, or Java‐based Web applications to run on a Web server somewhere.
“Class libraries published by the Android project, Apache Harmony, and other groups”
When you build a bridge, you typically do not start by opening an iron mine. Rather, you build the bridge from a mix of pre‐fabricated and custom parts. Pre‐fabricated parts might include girders and rivets. Somebody else was responsible for creating those girders, somebody else was responsible for mining the iron ore used to create the steel used to create the girders, and so on.
Similar, in software development, applications are rarely created completely from scratch. Instead, developers take advantage of pre‐fabricated software routines. One term for those, used in “object oriented” languages like Java, is a “class library”.
I mentioned earlier that there are many things that are called “Java”. Besides the syntax of the source code, some people refer to certain class libraries as being “Java”. Sun developed three major flavors of these class libraries, one for conventional desktop environments (Java SE), one for a limited mobile environment (Java ME), and one for server‐based Web applications (Java EE).
Android has class libraries. Some of those class libraries were written by the core Android team, made up of Google employees and contributors from other firms. The rest of the class libraries come from other open source projects. Notable among these is Apache Harmony, a project aiming to create a complete replacement implementation of all pieces of Java.
Specifically, Harmony offers a class library that is generally compatible with classes that come from Java itself — they have the same names for classes, for example. Android has included some — but not all — of the Harmony classes in the Android OS. Hence, Android developers can write code that use “Java” classes, despite the fact that those classes did not come from Sun and whose copyrights are not held by Oracle.
Java VM bytecode
Yet another thing that people sometimes refer to as “Java” is the Java virtual machine, or Java VM for short.
Many programming languages are “compiled”, meaning that a tool converts the source code that developers type in into something that a “machine” can execute directly. You can think of this as akin to converting a singer’s voice into the bits and bytes that go into an MP3 file or onto a CD.
Many compiled programming languages are compiled into ”opcodes” that are designed to be run by some specific sort of chip. There are opcode sets for the Intel chip in your notebook, and other opcode sets for the ARM chip in your smartphone, and still other opcode sets for the MIPS chip in your DVD player. If you want your source code to run on all three types of chips, you would need to compile it three times.
Some compiled programming languages, though, target not a real chip, but a fake one — a virtual machine. A virtual machine (VM) is a piece of software that mimics the functionality of a real chip. It runs bytecode (the VM equivalent of opcodes) designed for that specific type of VM. Different versions of the VM software can then be written to run on different types of real chips (Intel, ARM, MIPS, etc.). This way, a compiled VM application can run on a wide range of physical chips, without having to recompile the source code to target each physical chip.
Java is perhaps the most famous language that uses a virtual machine — the JVM. It was not the first and is not the only such language. Other popular languages that use VMs include Perl, Python, and Smalltalk — the latter is the language behind the Squeak app that Apple removed from the App Store for violating its “Apple‐only languages” policy. Similarly, Microsoft’s .NET languages (e.g., VB.Net, C#) run on a virtual machine called the Common Language Runtime (CLR).
The javac compiler that comes with the Java SDK
Still another thing that some people refer to as “Java” is the Java software development kit, or Java SDK (or, occasionally, JDK).
The Java SDK represents the set of tools and files needed by a programmer to write Java applications. Among other things, it includes a compiler tool — javac — that converts Java source code into Java bytecode that can be executed by the Java VM.
Dalvik VM bytecode
The Dalvik VM is a virtual machine, along the lines of the Java VM, the Parrot VM (Perl), Microsoft’s CLR, and so forth. Dalvik was written principally for use with Android, though some have experimented with using it separately.
Each VM has its own bytecode, just as each type of CPU chip has its own opcode. Hence, the Dalvik VM bytecode is not the same as the Java VM bytecode, or the Parrot VM bytecode, etc.
Translate the Java VM bytecode
That being said, Android does come with tools that translate compatible Java VM bytecode into Dalvik VM bytecode. This allows developers to write Java‐syntax source code, compile it with the Java SDK’s compiler, then get Android‐compatible Dalvik VM bytecode in the end.
Note that not all Java VM bytecode is compatible with the translation process, and therefore with Dalvik by extension. Notably, old bytecode (Java 1.4.2 and previous) and bytecode compiled by non‐Sun Java compilers will fail to translate.
An instance of a Dalvik VM
A Java program is run by a Java virtual machine. The VM reads in the Java bytecode, finds the desired entry point (a main method on a designated class), and executes the bytecode instructions. Similarly, an Android program is run by a Dalvik virtual machine.
If you wanted to run two separate Java programs at once, you will usually wind up with two copies of the Java virtual machine running on your computer. Similarly, when you run more than one Android application, each application usually gets its own Dalvik VM instance.
So, Why Dalvik?
OK, so, why did anyone bother to create Dalvik in the first place? Why not just use plain ol’ ordinary Java?
I do not claim to know all of the rationale behind the decision. That being said, here are at least some of the known technical reasons:
Memory Consumption
As noted above, if you want to run more than one Java or Android application, each application gets its own virtual machine instance. However, in Java, that will require a substantial amount of RAM, and on Dalvik it does not.
Why? Sharing.
Much of what is in a VM is read‐only. For example, the class libraries each VM uses do not typically get modified when a program using those libraries is run.
In Java, each application gets its own copy of all the read‐only portions of the VM.
In Dalvik, each application shares one master copy of all the read‐only portions of the VM, using techniques like copy‐on‐write.
As a result, Android, through Dalvik, can run more programs in a tightly‐constrained memory environment, like a smartphone.
Security
Saving memory is good. It allows us to do more with less. However, with Dalvik, there is an extra important benefit: it gives us better security that might otherwise be possible.
Linux has a security model baked into the kernel, one involving users and permissions. Each Linux program is run under a certain user’s account, whether that be a real person or a fictitious account for a particular program (e.g., an apache account that runs a Web server). All files in a proper Linux filesystem are owned by some user. Files that are marked as usable only by the user can be read and written to by that user’s own program, but cannot be read or modified by any other program, since other programs run as other users.
With me so far?
In Android, by default, each application gets its own user account — akin to the apache scenario above. When you run an Android application, it can access its own files, but it cannot access other applications’ files by default, courtesy of it running as a certain user.
This is only possible because of the memory sharing described in the previous section. If Android were limited to a traditional Java VM, each program would take up too much memory. Android applications might all have to share a single Java VM and all run as the same user, meaning one application could access another application’s data. You would have to layer all sorts of security cruft into the Java/Android environment to isolate applications from one another.
But, the memory sharing means each Android application can have its own Dalvik VM and run under its own user account. As a result, we get the tried‐and‐true Linux security model, making it significantly less likely that one application will be able to abscond with another application’s data.
Register‐Based VM
There are two ways to implement a virtual machine, “stack‐based” and “register‐based”. Java VMs tend to be stack‐based. The Dalvik VM is register‐based. This too is an optimization designed for mobile environments, where RAM is limited, as you can get more stuff done in fewer bytes, on average, with a register‐based architecture.

REFERENCES

http://www.groklaw.net/article.php?story=20100915143729255

Tuesday, August 10, 2010

I never really understood: what is CGI?

SkyHi @ Tuesday, August 10, 2010

CGI is a Comman Gateway Interface. As the name says, it is a "common" gateway interface for everything. It is so trivial and naive from the name. I feel that I understood this and I felt this every time I encountered this word. But frankly, I didn't. I'm still confused.



I am a PHP programmer. I did lot of web development.



user (client) request for page ---> webserver(->embedded PHP interpreter) ----> Server side(PHP) Script ---> MySQL Server.



Now say my PHP Script can fetch results from MySQL Server && MATLAB Server && Some other server.



So, now PHP Script is the CGI? because its interface for the between webserver & All other servers? I don't know. Sometimes they call CGI, a technology & othertimes they call CGI a program or someother server.



  • What exactly is CGI?

  • Whats the big deal with /cgi-bin/*.cgi? Whats up with this? I don't know what is this cgi-bin directory on the server for. I don't know why they have *.cgi extensions.

  • Why does Perl always comes in the way. CGI & Perl (language). I also don't know whats up with these two. Almost all the time I keep hearing these two in combination "CGI & Perl". This book is another great example CGI Programming with Perl Why not "CGI Programming with PHP/JSP/ASP". I never saw such things.

  • CGI Programming in C this confuses me a lot. in C?? Seriously?? I don't know what to say. I"m just confused. "in C"?? This changes everything. Program needs to be compiled and executed. This entirely changes my view of web programming. When do I compile? How does the program gets executed (because it will be a machine code, so it must execute as a independent process). How does it communicate with the web server? IPC? and interfacing with all the servers (in my example MATLAB & MySQL) using socket programming? I'm lost!!

  • They say that CGI is depreciated. Its no more in use. Is it so? What is its latest update?




Once, I ran into a situation where I
had to give HTTP PUT request access to
web server (Apache HTTPD). Its a long
back. So, as far as I remember this is
what I did:



  1. Edited the configuration file of Apache HTTPD to tell webserver to pass
    all HTTP PUT requests to some
    put.php ( I had to write this PHP
    script)

  2. Implement put.php to handle the request (save the file to the location
    mentioned)



People said that I wrote a CGI Script.
Seriously, I didn't have clue what
they were talking about.




  • Did I really write CGI Script?


I hope you understood what my confusion is. (Because I myself don't know where I'm confused). I request you guys to keep your answer as simple as possible. I really can't understand any fancy technical terminology. At least not in this case.



EDIT:



I found this amazing tutorial "CGI Programming Is Simple!" - CGI Tutorial Which explains the concepts in simplest possible way. After reading this article you may want to read Getting Started with CGI Programming in C to supplement your understanding with actual code samples. I've also added these links to this tutorial to Wikipedia's article : http://en.wikipedia.org/wiki/Common_Gateway_Interface



9 Answers

CGI is an interface which tells the webserver how to pass data back and forth to and from an application. More specifically, it describes how request information is passed in environment variables (such as request type, remote IP address), how the reqeust body is passed in via standard input, and how the response is passed out via standard output. You can refer to the CGI specification for details.



To use your image:



user (client) request for page ---> webserver ---[CGI]----> Server side Program ---> MySQL Server.



Most, if not all, webservers can be configured to execute a program as a 'CGI'. This means that the webserver, upon receiving a request, will forward the data to a specific program, setting some environment variables and marshalling the parameters via standard input and standard output so the program can know where and what to look for.



The main benefit is that you can run ANY executable code from the web, given that both the webserver and the program know how CGI works. That's why you could write web programs in C or Bash or Brainfuck with a regular CGI-enabled webserver. That, and that most programming environments can easily use standard input, standard output and environment variables.



In your case you most likely used another, specific for PHP, means of communication between your scripts and the webserver, this, as you well mention in your question, is an embedded interpreter called mod_php.



So, answering your questions:




What exactly is CGI?




See above.




Whats the big deal with /cgi-bin/*.cgi? Whats up with this? I don't know what is this cgi-bin directory on the server for. I don't know why they have *.cgi extensions.




That's the traditional place for cgi programs, many webservers come with this directory pre configured to execute all binaries there as CGI programs. The .cgi extension denotes an executable that is expected to work through the CGI.




Why does Perl always comes in the way. CGI & Perl (language). I also don't know whats up with these two. Almost all the time I keep hearing these two in combination "CGI & Perl". This book is another great example CGI Programming with Perl Why not "CGI Programming with PHP/JSP/ASP". I never saw such things.




Because Perl is ancient (older than PHP, JSP and ASP which all came to being when CGI was already old, Perl existed when CGI was new) and became fairly famous for being a very good language to serve dynamic webpages via the CGI. Nowadays there are other alternatives to run Perl in a webserver, mainly mod_perl.




CGI Programming in C this confuses me a lot. in C?? Seriously?? I don't know what to say. I"m just confused. "in C"?? This changes everything. Program needs to be compiled and executed. This entirely changes my view of web programming. When do I compile? How does the program gets executed (because it will be a machine code, so it must execute as a independent process). How does it communicate with the web server? IPC? and interfacing with all the servers (in my example MATLAB & MySQL) using socket programming? I'm lost!!




You compile the executable once, the webserver executes the program and passes the data in the request to the program and outputs the received response. CGI specifies that one program instance will be launched per each request. This is why CGI is inefficient and kind of obsolete nowadays.




They say that CGI is deprecated. Its no more in use. Is it so? What is its latest update?




CGI is still used when performance is not paramount and a simple means of executing code is required. It is inefficient for the previously stated reasons and there are more modern means of executing any program in a web enviroment. Currently the most famous is FastCGI.


REFERENCES
http://stackoverflow.com/questions/2089271/i-never-really-understood-what-is-cgi/2089297#2089297




The Secret to Learning Anything

SkyHi @ Tuesday, August 10, 2010
Some of the most important lessons I learned in college came from one professor,
Michael Mitzenmacher. Now,
this was a guy with a lot of papers to his name, tenured at Harvard,
working on some pretty darn complicated computer science theory (I took his
algorithms class). So you'd expect that I'd learn something important. But as
it turned out, the biggest lessons I learned from him weren't on the topics he
taught. I learned a secret that helped me learn much more effectively.


At one point when describing the problem sets in the class, he gave some advice
that stuck with me:


Don't suffer from Math Major syndrome

So, what you ask, is Math Major syndrome? Well, think of it this
way--if you are studying a hard problem, what's your first tendency? To get
lost in thought? To start at it, mulling over ideas in your head, waiting for
a flash of insight? If so, that's math major syndrome. It's the idea that you
can (or have to) solve problems entirely through a brilliant flash of insight,
without doing any actual work.




The alternative is quite simple:

Hard problems become easier by working through them with diagrams, effort and patience

In other words, don't just wait for answers to come to you--go out and find
them. Don't just use what's in your head--use paper, or the computer, or a
whiteboard, to draw out the ideas, try experiments, make the patterns
visible rather than waiting for a flash of insight.


I remember really learning this lesson during the first problem set--I'd
started it when it was handed out, but the night before it was due I still had
one problem left. I spent hours on that problem, but I spent it drawing out
equations, working through possiblities. Each one ended in failure, until I
had a flash of insight in the middle of writing out an equation. If I hadn't
worked through (and discarded) all those possibilities, I'd have had no hope of
solving that problem.


So how do you apply this principle in practice?

Program Program Program

If you're learning to program, you should be programming. Work practice problems while you
read tutorials--in fact,
you're probably better off in most cases working practice problems than
you are reading about programming. (You will need to read, but without
practice, that reading means nothing.)


In fact, if you're just learning to program, then I suggest that you stop
reading this article right now and go write some code (or get yourself
set up with a compiler and
then go write some code). But not something you know how to solve--try to
write a program that is just a little bit scary or hard. You should feel just
a bit scared that you won't be able to do it.

Draw it Out

A second corollary to the principle is that you're better off using paper than
trying to imagine everything. In fact, I can't say enough about the importance
of drawing diagrams. A lot of things in programming sound very abstract or
difficult to describe in words, but they can be quickly shown with a picture.
Computer memory, for example, can be thought of as a long block of cells
(almost like in an Excel spreadsheet). Drawing out each piece of memory in
your program (when dealing with pointers or data structures) can really help
visualize what is going on. You can also write out recursion manually by
showing each recursive call with its arguments and return value.


But even simpler concepts become clear when you draw them or work through them
step by step--having trouble understanding a complex piece of code? Write out
the different variables and how they are modified. For example, the boolean
expression

! a || b


(in other words, NOT a OR b)

has a very specific meaning in English: "if a is true, then b must be true";
this could be useful for checking user inputs ("if the user pressed exit, then
the game must be over--otherwise, print out an error"). But it's not
at all obvious what ! a || b means unless you actually work through it. What
do I mean?

The statement "if a is true, then b must be true" requires that:

if a = true, b must be true<br />if a = false, b can be either true or false<br />

How does that work for the expression "! a || b? You can draw out the table by
writing a in one column, b in a second, and whether the condition is satisfied
result in a third:

ab! a || b
001
011
111
100

Now you can more quickly see that the table expresses the English condition.
The condition is satisfied in all the cases except when a is true and b is
false (clearly, that can't satisfy an expression that says, "if as is true,
then b is true"!)



Being able to look at the data really helps!

Related Articles


Sunday, August 8, 2010

Common Programmer Health Problems

SkyHi @ Sunday, August 08, 2010


I'm currently working on the last few lessons in Learn Python The Hard
Way
and I want to include a lesson
on general health problems programmers run into during their careers. I
find many programmers seem to ignore their body's physical state when
they're coding, most likely due to the intense concentration required.
I'm hoping other people could benefit by simply understanding a few
health related problems programming has almost caused me or caused many
other people I know, and how I avoided them.



I probably won't put this whole blog post into LPTHW since it's a bit
much, but I will make a shorter version of it. Please feel free to let
me know if you hate it or like it or if you have some additional
resources I could reference.



My Background And Qualifications



In the past I was a top qualified soldier in the US Army, and I have
studied many martial arts. These days I'm not as into working out and
studying martial arts as I used to be, instead focusing on yoga,
meditation, and simpler activities. When I was younger I was incredibly
fit, and still am because of habits and practices I ingrained in myself
from an early age.



First a quick list of martial arts I've studied for various periods of
time: Ninjitsu, Aikido, Judo, Muay Thai, Wing Tsung, Capoeira, and
Arnis in no particular order. I would say only Muay Thai is the one I
studied most consistently, for probably about 6 years. The others I
studied for about 1 or 2 years if I could. I moved around a lot so the
only way to study was whatever was in the area.



Also, in the US Army I was at the top of my physical fitness exam, going
from barely passing to maximum scores consistently in about 2 years.
This involved about 2-4 hours of working out nearly every day if I
remember it correctly, which in the Army isn't that difficult. There's
really nothing else to do.



Finally, I've been the exact same weight, flexibility, and nearly the
same strength my whole life, whether I worked out or not, which means
that I probably can't tell you about how to lose weight. I'm most
likely genetically predisposed to be this way. That means you should
adapt my advice to fit your life and what you've found healthy.



With all that being said, as I've gotten older I much more enjoy the
less violent and more "supple" forms of exercise. I feel Yoga is
excellent exercise because it's deceptively difficult. I'd also vote
for Pilates, swimming, dance, and anything that doesn't cause direct
impact on my body. I especially have to watch out for my hands for
reasons I'll explain in a bit.



Alright, that should give you an idea that I know something, but more
importantly, while doing all of these things, I also wrote software
professionally. After getting out of the Army I averaged about 8-16
hours of coding and study a day. I also touch type and I play guitar,
yet I've mostly avoided carpel tunnel and other RSI problems.



Hopefully, my experience maintaining my physical health will help you
gain some or keep yours.



Common Problems Programmers Face



Programming is a deceptively damaging field to be in, partly because it
doesn't seem like you're doing much, and also because of the attitude
many programmers have toward their body. You should care about keeping
yourself healthy because, when your body is in good shape, that removes
"friction" from your mental capacity so that it can focus on important
things rather than annoying little problems with your physical wellness.



Obviously the advice on eating right, going outside, getting exercise
has been said by everyone. I'm not really going to tell you how to eat,
or work out, or how to do a martial art or something else to stay
healthy. If you are interested in those things, then please find a
professional who can train you and help you.



What I do want to cover are a set of particular problems programmers
have from their daily profession. These are just simple really obvious
things that for some reason programmers don't realize aren't supposed to
be happening:



  • Pain in your wrists from Repetitive Strain Injury (RSI).
  • Problems with your eyes from staring at moving print for extended periods.
  • Back problems from poor posture, especially in the lower back and upper shoulders.
  • Bowel and urinary issues from not crapping and pissing when you should.
  • Dehydration from drinking too much caffeine and not enough water.
  • Problems with hemorrhoids and the prostate for guys from sitting too much. Yep, I'm gonna go there.
  • Vitamin D deficiency from lack of sunshine.
  • Sleeping disorders from staying up late and drinking too much coffee.
  • General stiffness and soreness from a lack of stretching in general.


I've had to struggle with all of these problems at one point in my life
because of programming, guitar, or actually from lifting weights wrong.
In each case I was able to get healthy and then avoid it the rest of my
life, and really only deal with a few problems periodically. You may
think some of these are stupid, but believe me, many programmers have
these problems for various reasons even if you might not.



The General Cause



Overall the general cause of all of these problems can be summarized as
treating programming as an obsession. You may want to be very good at
it, like I did, so you exclude everything else in your life in order to
master it. You don't go to the bathroom, you have macho 10 hour coding
sessions, you don't eat right, and all manner of mythological beliefs
about "real programmers".



Truth is real programmers are kind of idiots. They don't eat right.
They don't have sex on a regular basis. They can't run without gasping
for breath. They have huge problems with their internal organs not
caused by disease. Really, it's just not worth it if you have to kill
yourself to be good at something.



So, as you read through each of these problems and how I've cured them,
remember that it's all about just having a balanced life and not being
obsessed with coding or your business. Trust me when I say you will
actually become better if you take it easy on yourself and stay
healthy.



Wrist Pain



This is probably the one I struggle with the most, because I code and
play guitar quite frequently and for long periods of time. I've had
pain in my wrists periodically since I started coding professionally at
22, but I always had a set of Aikido exercises I did to get my wrists
straight.



You see, Aikido has these fantastic wrist exercises that make your
wrists strong and supple at the same time. They developed the exercises
to avoid injuries during practice since many of the Aikido techniques
involve wrenching, ripping, and breaking the joints in the arms, wrists,
and shoulders.



For me these exercises have always fixed any misalignment and pain, and
they've allowed me to code for long periods of time without much
trouble. Typically the only time I'll have problems is if I've switched
keyboards and have a new odd keyboard layout, but if I do I simply do
the exercises for about a week every time I go to code and they get
strong again.



Now, if you have serious carpel tunnel or another kind of RSI then
consult your physician before trying these. If you do them, then start
very slowly, and do not try to make them hurt. Stretching should not
hurt, it should just be "mildly uncomfortable". If it hurts, then you
are straining to do the stretch.



What you actually want to do is relax into every stretch you do. It's
hard to explain, but instead of forcing your joint to a certain
position, bring it to that position and then think about relaxing it or
"letting" it move a bit further.



Keep this in mind, and then here's a set of videos that show you how to
do each exercise:





Here's how you use these exercises before you sit down to type (every
time!):



  1. First, you need to warm up, so put your hands out in front of you and
    grab at the air as fast as you can 20 times. Then shake your hands,
    then rotate your wrists 10 times one direction and 10 times another.
  2. Start with the first exercise you're best at, and do 5-10 of them at
    a medium speed.
  3. Continue through each one, but after each one shake your hands and
    arms and rotate your wrists to realign them. These exercises do some
    moving of the bones in your wrist, so shaking them sort of makes them
    settle back in.
  4. NEVER do too much strain on your wrists. Do just enough to get them
    going and feeling supple and relaxed, but the motto "no pain no gain"
    will only damage you.


Do these each time you go to type, every day, and any time you stop. It
doesn't take long to do them, and after a bit of discomfort as your
wrists start to adapt and get realigned, you'll start to feel better.



One more time though: DO NOT DO THIS WITHOUT CONSULTING A DOCTOR
FIRST
You do these at your own risk, so don't sue me if you fuck up
your wrists because you didn't pay attention. These exercises have been
done for maybe thousands of years in various martial arts, so I know
they aren't dangerous but everyone is different. You could screw
yourself up bad if you do them wrong, so if it hurts stop doing them
and talk to a doctor!



Guitarists Are Worse



Programmers will get RSI but it's nothing compared to what guitarists
and bassists get. For various stupid reasons there's myths around many
of the big name musicians and their claims of studying "8 hours a day"
or "16 hours a day!". Because of this guitarists will kill themselves
and damage their hands making it impossible to play.



Guitar is a hard instrument on your hands, so even a little pain can put
you out of commission. I learned this the hard way in school because,
like an idiot, I believe my instructors when they said I had to study 8
hours a day. I literally thought they meant 8 hours straight, so I did
that for about a month and then BAM!



Fucked up my thumb and gave it a bone spur and all my fingers hurt like
crazy. My wrists were solid, but my fingers just couldn't take it.
Like an idiot I didn't listen to what I already knew which is any new
activity has to be gradually increased like any other work out.



The only way I could fix this, and it took nearly 1.5 years, was to do
the following:



  1. Find guitars that didn't hurt my hands. The idea that you can "play
    any guitar" is crap. Get the best guitar you can that doesn't hurt you.
  2. Do the above exercises, and then some more for my fingers.
  3. Start slowly rebuilding my fingers and thumb by doing a set of
    exercises to improve their strength and relaxation.
  4. Constantly focus on relaxing while playing so that I could use a
    lighter touch.
  5. Avoid bends as they hurt my hands and caused me injuries.
  6. Changed my position and playing style so that I'm able to move around
    quickly without having to grip the guitar, instead my thumb is on the
    back of the guitar where it's comfortable.
  7. Adjusted the height of my guitar so that it was comfortable
    on my shoulder and hands to play.
  8. Always play standing up now, rarely sitting down for long periods of
    time because the position is awkward, and if I do I keep the same
    position.


After doing that for the last year my hands are finally feeling good and
have healed up, and I've not got good habits that prevent me from
injuring myself. I'm an old guy so these things are important, but that
also means I can't do anything that might hurt my hands.



My hands are my life right now, so that means no boxing, capoeira, or
anything else I really want to study. I have to much riding on my hands
to waste it on a punching bag.



Eye Strain



I think this isn't as much of a problem as it was for me, but you have
to watch out for your eyes. I had perfect better than 20/20 vision when
I was younger, but from decades of computer use my eyes are "slightly
off". I have a minor correction in glasses and these days I just wear
them all the time even if I only need them a little bit. The world is
just annoyingly fuzzy without them.



Back in the bad old days we stared at CRT screens all day, which had
horrible annoying flicker and screwed up quite a few eyes. These days
it's not the flicker so much as the poor font rendering on most LCD
screens. Thanks to patents owned by Apple (I think) many computers
can't render fonts well on an LCD screen. Some folks though think
Apple's font rendering looks "fuzzy" so your mileage may vary
considerably.



In my case I try to get out for about 2 hours a day and not look at a
computer. Either I do something that doesn't involve reading like play
guitar, or I go for a walk or to the park. I may not do this for a full
2 hours but I try to not start at a computer screen for at least 2 hours
a whole day.



This will also help with headaches you might have. Frequently
programmers will think that the lighting in a room is what gives them
headaches from using a computer, but really it's bad posture, shitty
fonts, not drinking enough water, and just using the computer for too
long at a stretch.



Instead of doing some extreme thing like turning out all the lights in
your office, just have good lighting and use a color scheme that fits
the type of LCD you have and the room's lighting. It's the combination
of room/area lighting, LCD brightness, LCD quality, fonts, and your
color scheme that will make you feel better.



But most importantly, just take a break.



Back Problems



I've been extremely luck to have a good solid back most of my life.
Even though I've been sitting in a chair for a good portion of that
life, I still have a good flexible and strong back.



For me, the problem is in my upper back, neck, and shoulders. I tend to
hunch over the keyboard and have to force myself to sit up straight.
In fact right when I started typing this section I noticed I wasn't
sitting up straight and had to correct it.



Now, the choice of chair matters, and I tend to like either Aeron chairs
of some kind of solid small stool or bench. I'm currently very much
liking my little $40 piano bench I used to sit on to practice piano.
It doesn't have a back so it forces me to sit up straight more often and
engage my core muscles (stomach and back muscles).



For my shoulders though it's entirely stress. I tend to "scrunch up" my
shoulders when I'm focused intensely and that causes my whole upper back
to hurt, sending pain all the way up my neck and head. It gets really
bad if I practice guitar for long periods at a time.



What I've found helps the most is stretching your upper arms and doing
push-ups. Stretching your upper arms is as simple as grabbing a door
jam, grabbing it, and pulling each arm or both arms in a different
direction. Try these if you're feeling stiff:



  1. Grab a door jam with one arm so your palm faces the front of your
    body, then pull your shoulder out so you stretch your chest and the
    front of your shoulder.
  2. Grab the door jam with one arm so that your arm crosses your body,
    and again with your palm facing the front (kind of backwards), then pull
    so your shoulder at the back is stretched.
  3. Put both arms on the door jam in front of you, right above your head,
    and stand away from it a bit so that you lean down and pull your arms
    above you and back.


If you do that, and also rotate your shoulders and shake your body out
you'll start to feel much better. Maybe combine this with your wrist
stretches before you work each day.



Another big help is doing some push-ups. I wouldn't do these at work or
before you work because it will make you tired and make it hard to work.
I'd instead just do 10 a night before you go to sleep. Just 10 will do
a lot for your chest, back, wrists, and neck. Don't do them very fast,
but do them slowly and focus on balancing your body when you do them.



Dehydration



This one is simple, and I'm guilty of it quite frequently. I find I
drink a ton of coffee, and because of that I have to make sure I drink
some water too. If I don't I get headaches and really don't feel right.
The problem with dehydration is it's hard for you to tell you're
suffering from it until it's too late.



What I suggest, and what I've started doing more, is that you drink a
bottle or cup of water with every non-water beverage you drink. I also
recommend you ditch the sodas. They're just full of nasty fake sugar
that make you fat and cause diabetes, and they're not rehydrating you.
If you gotta drink something then plain black coffee is pretty damn
good, but again drink some water with it.



Bowel And Urinary Problems



Alright the next two are kinda gross so I won't go into what happened to
me, but I'll say this:




Go to the fucking bathroom right when you have to go. Don't wait.




You wouldn't believe how useful this advice is and I really wish I'd
been told it when I was younger. Because I would code non-stop like a
"real programmer" I would skip bathroom breaks and hold it in for far
too long. The problem is with bowel movements your body just stops
telling you to crap, and then it builds up.



This eventually leads to constipation and it's a motherfucker on your
health. For your urinary tract it causes problems that are less
important, but you can get infections and other nice little surprises.



If you've already screwed up, the best thing to do is go get some fiber
tablets and take them then stay home 'cause it's gonna get ugly.



Then, when you feel you need to go, just get up and go for the love of
god. I'm telling you, your brilliant idea will come more naturally
after you poop.



Hemorrhoids and Prostate Health



The other problem you have from not using the restroom when you should
is that you get hemorrhoids. Yeah yeah, I know, really gross and I
promise this is the only time I'm gonna mention them ever. But, many
programmers have them and are ashamed to talk about them or even know
what causes them so I'm going to lay it out for you. I've actually done
all of these but only had them once or twice:



  1. Sitting for a long period of time.
  2. Lifting heavy weights without proper equipment.
  3. Not taking a dump when you actually need to.
  4. Forcing a dump when you don't need to.
  5. The worst one though: Sitting on the toilet reading.


This last one is the killer let me tell you. If you don't have to go,
then do not sit on the can hanging out. What this does is put all the
weight of your body and bowels on your already probably screwed up rectum
and then pushes it out. Nasty. That also then causes hemorrhoids
because the pressure increases in your blood vessels unnaturally.



These are just freaking gross, but they're also potentially harmful.
Yes, you can get some that are so bad you bleed all over the place. If
you have some, please go see your doctor and deal with it. You may need
surgery, so just do it. I didn't but man it was close. One year I was
lifting weights, working in a warehouse, coding non-stop, and not using
the bathroom.



Yep, I was idiot, so don't make the same mistake. Make sure you do
these three things to keep your ass healthy:



  1. Eat some veggies regularly, or eat some fiber tablets at least.
  2. Go to the bathroom right when you have to go.
  3. Don't force pressure down there in any way.


This can also damage your prostate if you aren't careful, but usually
that's from sitting on your ass all day. Just get up and walk around or
take breaks and you'll fix that problem. If you find blood in your
urine or you have problems peeing, go see a doctor because it might be
more serious. If you pee a lot it can also be bad, so again see a
doctor.



Vitamin D Deficiency



Vitamin D is weird. You really only get it from the Sun but you don't
need much direct sunlight to get it. Maybe like 5-30 minutes depending
on how strong it is. It's also tied to your calcium levels, and a lack
of phosphate, but if you eat regularly and something other than potato
chips that shouldn't be a big problem.



Some of the things you can get are depression, screwed up teeth, pain in
weird places like in the bones in your arms, cramping muscles, and just
generally feeling like crap. If you're really bad you might need to get
a prescription from a doctor, but usually you can just make a plan to go
outside for 30 minutes when the Sun is high in the sky.



In fact, I think this is one of the problems with catered food at many
startups here in the Valley. Since you are inclined to stay in the
office and eat food and constant leftovers, and because many offices
have poor lighting, you tend to not go outside when the Sun is out.
Combine that with poor sleeping habits and you can really be screwing up
your vitamin D levels without knowing it.



Just something as simple as not eating the catered lunches and walking
outside at noon to get your food could help more than you know. Anyway
the food is better.



I got minor vitamin D deficiency when I lived in Vancouver and Seattle.
Up there you just don't have sunshine for months on end, and for me that
was a killer. Some people can handle it, but for people like me who
lived on a tropical islands in his teens, this was just murder.



So, if you have sunshine, get out and grab some when you can.



Sleeping Disorders



I've always had a flexible sleep schedule, usually depending on the
season and the region. In some areas I trend toward a night owl persona
and stay up really late doing things then sleeping in. Lately since
moving to SF I've been getting up earlier and not staying up as late,
and I've actually been feeling really good lately.



Sometimes though, and I'm not sure why, I feel way more productive in
both music and coding late at night, or very early in the morning. I
think it's because I'm still in a tired state and so my brain is
relaxed. I also think it's because it's very quiet and I can just hang
out and think with no distractions.



Either way, this need to either get up very early or stay up very late
sort of screws with my sleep schedule. I find that I much prefer
getting up early as I get older. I feel more awake and rested during
the day. If I stay up late and sleep in I feel like I have a hangover
and I can get headaches.



If you have problems sleeping though, I have a very simple kind of
meditation that I've been using for years to help you crash. It takes a
bit of practice, but it totally works and works quickly.



First up, if you can, get the best damn bed you can afford. 2000+ dollars is
nothing for a great bed. I spent at least 2200 on a sweet Tempur-Pedic.
It's totally worth it.



Now with your awesome bed here's how you start practicing getting to
sleep easily. It's kind of a self-hypnosis trick:



  1. Make sure that you've killed all sounds and lights that might be in
    your room.
  2. Lay on your back and put your hands on your body somewhere
    comfortable, or at your sides.
  3. Start breathing in deeply and slowly and breathing out, as you do
    this imagine you can see the air flow in and out of your body.
  4. Once you start to see your breath, imagine that you're looking
    through a window and outside the window is a large huge open space with
    stars in it.
  5. As you breath feel yourself float through the window and slowly out
    into the massive expanse of stars, all floating softly around you.
  6. Keep this going and then just let this floating spread into your bed
    and out around you until there is nothing.


You probably will crash out at around 4 or 5, but if not just hang out
and keep letting yourself float and melt until you do.



If you have severe insomnia then definitely talk to a doctor about it,
but try this out, as well as exercising like crazy for about an hour or
two a day. Exercise will definitely make you sleep.



Stiffness And Flexibility



If you constantly feel "stiff" or unable to move well, then you probably
need to stretch regularly. Really the best thing you can do is go to
yoga about once a week, and then try to do the exercises on your own.
If you can't do that, then go get any number of books on basic
stretching from the library or from a book store. You really just need
a simple book on the subject, and you don't need to do too many.



I think if you did about 5-6 big stretching exercises a night before
sleeping you'd feel very relaxed and see a major improvement in your
general health and feeling.



Relaxing your body through stretching relaxes your mind as well, so a
great way to improve your creativity and boost your ideas is to do yoga
or stretching for about 30 minutes, then take your morning shower.
Combine this with some meditation and you'll start to see a major
improvement in your general ability to mentally adapt and start to see
yourself make odd connections you wouldn't have before.



I'm not sure why this is, but a relaxed mind is crucial to spontaneous
creativity and idea generation.



A Simple First Step



This is probably a lot of information for one person, and I seriously
hope that you don't have all of these problems. What I recommend though
if you don't have these issues is that you try to avoid them. If you're
just starting out then you need to maybe adopt a simple "coding warm-up"
routine you can go through before you code.



Here's what I do before I sit down to code, or before I play guitar, and
whenever I get stiff and need a break:



  1. Rotate all the joints in your body by just moving your wrists, arms,
    neck, back, and hips in a few little circles. Say 5 one direction, then
    5 in another direction.
  2. Do a small number of the wrist exercises and shake your wrists
    between each set.
  3. Stretch your arms above your head as high as you can, and then
    stretch them back as far as you can, and then pull them across the front
    of your body.
  4. Finally, carefully use your hand to pull your head to the right,
    left, forward, and back a bit.


If you just did this you would avoid quite a few programming injuries.
Since programming isn't really that physically taxing it's fairly easy
to avoid hurting yourself, so this is really all you need.



However, if you have a specific problem, then again consult a physician
and try some of my advice if they say it's alright. Nothing I'm
proposing here is radical or weird, just basic exercises and common
sense, so it should be alright with any doctor. I just don't want to
get sued so remember I told you to ask one first.



Hopefully that helps you out, and if not just remember the advice in
case you run into these. If you're lucky they won't be a problem but I
think every programmer I know has had something like this at least once.



If you have other problems along these lines, then feel free to email
me
and I'll reply with some advice.



Take care.




REFERENCES
http://sheddingbikes.com/posts/1281257293.html
http://news.ycombinator.com/item?id=1585085

Sunday, May 16, 2010

Securing your URL with Hexadecimal codes

SkyHi @ Sunday, May 16, 2010

Hexadecimal equivalent codes of ASCII characters can be used to represent characters of a URL’s path and filename.


Each hex number is preceded by a “%” symbol to identify the following two numbers/letters as a hexadecimal representation of the character


An ASCII chart can be used for the conversion from ASCII to Hex or vice versa


One good source for ASCII to Hex charts is http://en.wikipedia.org/wiki/ASCII (both the tables below have been taken from this URL)


 



 



 


The need for typing in Hex codes into a URL is to make it possible to include special characters in a URL which would otherwise be wrongly interpreted or not allowed. A good example is SPACE which would not be able to fit into a URL in its original form and hence is represented by the Hex code 20 (prefixed by % in a URL making it %20)


 


For example, if we were to visit the URL www.bing.com , it could be written as


 


B =  %42


I = %49


N = %4e


G = %47


 


Hence, www.bing.com could be written as www.%42%49%4e%47.com


 


Note: The “slashes” in the address cannot be represented in hex; nor can the IP address be rendered using this logic (the %XX way) but the rest of the URL can be manipulated



REFERENCES

http://www.zerointellect.com/security/securing-your-url-with-hexadecimal-codes/comment-page-1/

Sunday, January 17, 2010

Top 10 Programming Fonts

SkyHi @ Sunday, January 17, 2010

I’m a typeface geek, and when it comes to selecting a font I’ll stare at all day, I tend to be pretty picky. Recently, when I discovered that a friend was using a sub par typeface (too horrible to name here) for his Terminal and coding windows, my jaw dropped, my heart sank a little, and I knew it was due time for me to compose this article.

What follows is a round-up of the top 10 readily-available monospace fonts. Many of these fonts are bundled along with modern operating systems, but most are free for download on the web. A few, notably Consolas, are part of commercial software.

A note about anti-aliasing

In the past, we’ve had to decide between tiny monospace fonts or jagged edges. But today, modern operating systems do a great job of anti-aliasing, making monospace fonts look great at any size. It’s not 1990 anymore. Give your tired eyes a break and bump up that font size.

If you have any doubt that anti-aliased fonts are apropos for code, note that even the venerable BBEdit — which for years has shipped with un-aliased Monaco 9 set as the default — has made the jump. The app now ships with a specially licensed version of the Consolas font from Ascender, bumped up in size, and with anti-aliasing on by default. Panic includes a special anti-aliased font (Panic Sans, which is actually just a version of Deja Vu Sans Mono) with its popular Coda application.

Unless otherwise noted, I’ve used a larger size font, 15-point in fact, for the examples here to illustrate their legibility at larger sizes and with anti-aliasing turned on.

10. Courier

All systems ship with a version of Courier (sometimes Courier New), and unfortunately, many have it set as the default font for terminal and editor windows. It does the job, but it’s a bit dull and boring, lacking style and class. I don’t recommend this font if you have any other choice — and fortunately, you do. If you use this font, please bump the size and turn on anti-aliasing.

Courier New Figure 1 Courier New

9. Andale Mono

A bit better than the Courier family, Andale Mono is still relegated to the “default font” category as it ships with some systems, and you wouldn’t want to download or use it if it wasn’t already there. The character-spacing is a bit too clumsy and the letters are a bit too wide for my tastes.

Andale Mono Figure 2 Andale Mono

8. Monaco

Monaco is the default monospace font on the Mac and has been since its inclusion in System 6. It’s a solid, workhorse font that really shines at smaller font sizes with anti-aliasing turned off. I loved this typeface back when my eyes could tolerate staring at a 9-point font for hours, but those days are behind me. This font looks great at 9 or 10-points (Figure 4), and doesn’t look too shabby anti-aliased at higher sizes (Figure 3).

As far as I know, you can only get Monaco as a part of Mac OS, but there are alternatives, so keep reading.

Monaco Figure 3 Monaco
Monaco 9 Figure 4 Monaco 9-point, without anti-aliasing

7. Profont

Profont is a Monaco-like bitmap font available for Mac, Windows, and Linux (there’s also a modified version for Mac OS X called ProFontX by a different author). They’re best at smaller sizes, and make a great alternative to Monaco if you’re on a non-Mac platform and want really tiny fonts and the eyestrain that goes along with them.

Profont (and ProFontX) is intended for use at 9-points with anti-aliasing turned off.

Profont Figure 5 Profont 9-point, without anti-aliasing

6. Monofur

Monofur is a unique monospace font that looks great anti-aliased at all sizes. It’s a fun font with a distinct look that is vaguely reminiscent of Sun’s OPEN LOOK window manager, which ran Solaris (aka SunOS) systems back in the late 80’s. If you’re looking for something a bit different, try this font, but make sure you have anti-aliasing turned on, even at small sizes.

Monofur Figure 6 Monofur

5. Proggy

Proggy is a clean monospace font that seems to be favored by Windows users, although it works fine on a Mac. It’s a clean font intended to be used only at smaller points, and without anti-aliasing.

Proggy Clean Figure 7 Proggy Clean at 15-point (yes, 15-point), without anti-aliasing

4. Droid Sans Mono

The Droid font family (available for download here) is a nice font family designed for use on the small screens of mobile handsets, like Android, and licensed under the Apache license.

Droid Sans Mono makes for a great programming font. It’s got a bit of flair, and stands out among the other monospace fonts I’ve listed, and its only real flaw is the lack of a slashed zero.

Droid Sans Mono Figure 8 Droid Sans Mono

3. Deja Vu Sans Mono

The Deja Vu family of fonts are one of my favorite free font families, based on the excellent Vera Font family. The Deja Vu fonts have been updated with a wider range of characters while maintaining a similar look and feel to that of Vera.

This was my go-to font family for many years. It looks great at any size with anti-aliasing turned on.

Panic ships a font with it’s Coda application called “Panic Sans” which is based on this font. Gruber says via email that when he compared Panic Sans against Vera, he noted that “Panic had noticeably crisper punctuation chars” and that it seemed like they had improved the hinting on some characters as well.

Deja Vu Sans Mono Figure 9 Deja Vu Sans Mono

2. Consolas

Consolas suddenly appeared on my Mac after I installed Microsoft Office, along with a handful of other new fonts from Microsoft.

This font was designed by Luc(as) de Groot for Microsoft’s ClearType font family (there’s a nice write-up with samples of each of the new Microsoft fonts here). Consolas is a commercial font, but is bundled with many Microsoft products, so there’s a good chance you might already have it on your system.

You’ll absolutely want to have anti-aliasing turned on if you’re using Consolas, because it’ll look terrible without it.

Too bad it’s not free … if it was, it would be #1 on this list.

Consolas Figure 10 Consolas

1. Inconsolata

Inconsolata is my favorite monospaced font, and it’s free. Shortly after discovering it, it quickly supplanted Deja Vu Sans Mono as my go-to programming font. I use it everywhere, from Terminal windows to code editors. It has a certain sublime style that’s unique without being over the top, and it looks fantastic at both large and small sizes. I use this font when I show code samples in a presentation, and it’s the font we use in Terminal and TextMate windows when filming PeepCode screencasts.

Inconsolata is designed to be used with anti-aliasing enabled, but it’s surprisingly legible even at very small sizes. A big thanks to Raph Levien for creating this font, and for making it free.

Inconsolata Figure 11 Inconsolata

Thoughts?

Did I miss your favorite coding typeface? Think the list is out of order? Let me know. If there’s a typeface you think should be in this list, please let me know in the comments section below. If it meets my ridiculous standards, I’ll review it and include it in a follow-up article.




Reference: http://hivelogic.com/articles/top-10-programming-fonts

Thursday, January 14, 2010

7 reasons I switched back to PHP after 2 years on Rails

SkyHi @ Thursday, January 14, 2010

SUMMARY: I spent two years trying to make Rails do something it wasn’t meant to do, then realized my old abandoned language (PHP, in my case) would do just fine if approached with my new Rails-gained wisdom.


INTRO / BACKGROUND:


Back in January 2005, I announced on the O’Reilly blog that I
was going to completely scrap over 100,000 lines of messy PHP code in
my existing CD Baby (cdbaby.com) website, and rewrite the entire thing
in Rails, from scratch.


I hired one of the best Rails programmers in the world (Jeremy
Kemper aka bitsweat), and we set off on this huge task with intensity.
The first few months showed good progress, and Jeremy could not have
been more amazing, twisting the deep inner guts of Rails to make it do
things it was never intended to do.


But at every step, it seemed our needs clashed with Rails’
preferences. (Like trying to turn a train into a boat. It’s
do-able with a lot of glue. But it’s damn hard. And certainly
makes you ask why you’re really doing this.)


Two years (!) later, after various setbacks, we were less than halfway done.*
(To be fair to Jeremy’s mad skillz: many setbacks were because of
tech emergencies that pulled our attention to other internal projects
that were not the rewrite itself.) The entire music distribution world
had changed, and we were still working on the same goddamn rewrite. I
said fuckit, and we abandoned the Rails rewrite. Jeremy took a job with
37 Signals, and that was that.


I didn’t abandon the rewrite IDEA, though. I just asked myself one important question:


“Is there anything Rails can do, that PHP CAN’T do?”


The answer is no.


I threw away 2 years of Rails code, and opened a new empty Subversion respository.


Then in a mere TWO MONTHS, by myself, not even telling
anyone I was doing this, using nothing but vi, and no frameworks, I
rewrote CD Baby from scratch in PHP. Done! Launched! And it works
amazingly well.


It’s the most beautiful PHP I’ve ever written, all wonderfully MVC and DRY, and and I owe it all to Rails.


Inspired by Rails:


*- all logic is coming from the models, one per database table, like Martin Fowler’s Active Record pattern.


*- no requires or includes needed, thanks to __autoload.


*- real MVC separation: controllers have no HTML or business-logic,
and only use REST-approved HTTP. (GET is only get. Any destructive
actions require POST.)


*- all HTML coming from a cute and powerful templating system I
whipped up in 80 lines, all multi-lingual and caching and everything


*- … and much more. In only 12,000 lines of code, including HTML templates. (Down from 90,000, before.)


Though I’m not saying other people should do what I’ve
done, I thought I should share my reasons and lessons-learned, here:


SEVEN REASONS I SWITCHED BACK TO PHP AFTER 2 YEARS ON RAILS:


#1 - “IS THERE ANYTHING RAILS/RUBY CAN DO THAT PHP CAN’T DO? … (thinking)… NO.”

For 2 years, I thought Rails is genius, PHP is shit. Rails is powerful, PHP is crap.

I was nearly killing my company in the name of blindly insisting Rails was the answer to all questions, timeframes be damned.

But when I took a real emotionless non-prejudiced look at it, I realized the language didn’t matter that much.

Ruby is prettier. Rails has nice shortcuts. But no big shortcuts I can’t code-up myself in a day if needed.

Looked at from a real practical point of view, I could do anything in PHP, and there were many business reasons to do so.


#2 - OUR ENTIRE COMPANY’S STUFF WAS IN PHP: DON’T UNDERESTIMATE INTEGRATION

By the old plan (ditching all PHP and doing it all in Rails), there was
going to be this One Big Day, where our entire Intranet, Storefront,
Members’ Login Area, and dozens of cron shell scripts were ALL
going to have to change. 85 employees re-trained. All customers and
clients calling up furious that One Big Day, with questions about the
new system.

Instead, I was able to slowly gut the ugly PHP and replace it with beautiful PHP. Launch in stages. No big re-training.


#3 - DON’T WANT WHAT I DON’T NEED

I admire the hell out of the Rails core gang that actually understand
every line inside Rails itself. But I don’t. And I’m sure I
will never use 90% of it.

With my little self-made system, every line is only what’s
absolutely necessary. That makes me extremely happy and comfortable.


#4 - IT’S SMALL AND FAST

One little 2U LAMP server is serving up a ton of cdbaby.com traffic damn fast with hardly any load.


#5 - IT’S BUILT TO MY TASTES

I don’t need to adapt my ways to Rails. I tell PHP exactly what I
want to do, the way I want to do it, and it doesn’t complain.

I was having to hack-up Rails with all kinds of plugins and mods to get
it to be the multi-lingual integration to our existing 95-table
database.

My new code was made just for me. The most efficient possible code to work with our exact needs.


#6 - I LOVE SQL

Speaking of tastes: tiny but important thing : I love SQL. I dream in queries. I think in tables.

I was always fighting against Rails and its migrations hiding my beloved SQL from me.


#7 - PROGRAMMING LANGUAGES ARE LIKE GIRLFRIENDS: THE NEW ONE IS BETTER BECAUSE *YOU* ARE BETTER

Rails was an amazing teacher. I loved it’s “do exactly as I
say” paint-by-numbers framework that taught me some great
guidelines.

I love Ruby for making me really understand OOP. God, Ruby is so beautiful. I love you, Ruby.

But the main reason that any programmer learning any new language
thinks the new language is SO much better than the old one is because
he’s a better programmer now! You look back at your old ugly PHP
code, compared to your new beautiful Ruby code, and think, “God
that PHP is ugly!” But don’t forget you wrote that PHP
years ago and are unfairly discriminating against it now.

It’s not the language (entirely). It’s you, dude. You’re better now. Give yourself some credit.


Ok. All that being said, I’m looking forward to using Rails
some day when I start a brand new project from scratch, with Rails in
mind from the beginning.


But I hope that this reaches someone somewhere thinking, “God
our old code is ugly. If we only threw it all away and did it all over
in Rails, it’d be so much easier!”


Reference: http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html

Wednesday, January 13, 2010

20/20: Top 20 Programming Lessons I've Learned in 20 Years

SkyHi @ Wednesday, January 13, 2010

I've been programming since I was 11 and I've loved technology and programming every since. There are some hard and easy lessons I've learned over time. As a fellow programmer, you may not have experienced these, but I'm offering them to individuals who are interested in learning more from my experiences.

I'll be updating this as time goes on. I may have more, but in my 20 year period, I don't think there are any additional rules that this list doesn't include. :-)

Here are my most memorable lessons so far.

  1. Set a duration of how long you think it should take to solve a problem - C'mon, admit it! I'm just as guilty as the next programmer. I've seen programmers sit in front of a monitor for eight hours at a time trying to solve a particular problem. Set a time table for yourself of 1 hour, 30 minutes, or even 15 minutes. If you can't figure out a solution to your problem within your time frame, ask for help or research your problem on the Internet instead of trying to be super-coder.
  2. A language is a language is a language - Over time, once you understand how one language works, you'll notice similarities between other languages. The language you choose should provide you with a suitable "comfort" level, the ability to produce efficient (and clean) code, and, above all, allow the language to suit the project and vice-versa.
  3. Don't over-"design pattern" applications - Sometimes it's just easier to write a simple algorithm than it is to incorporate a singleton or facade pattern. For the most part, it even allows for cleaner, understandable code. :-)
  4. Always backup your code - I've experienced a complete hard drive failue and lost a lot of code when I was younger and felt horrible because of what had happened. The one time you don't back up your data may be the one time where you have a strict deadline with a client and they need it tomorrow. Source code/version control applies here as well.
  5. You are not the best at programming. Live with it. - I always thought that I knew so much about programming, but there is always someone out there better than you. Always. Learn from them.
  6. Learn to learn more - With number five explained, I've always had a magazine or book in my hand about computers or programming (ask my friends, they'll confirm). True, there is a lot of technology out there and keeping up with it is a fulltime job, but if you have a smart way of receiving your news, you'll learn about new technology every single day.
  7. Change is constant - Your knowledge of technology and/or programming should be similar to how you treat stocks: Diversify. Don't get too comfortable with a particular technology. If there's not enough support for that language or technology, you might as well start updating your resume now and start your training period. My general rule of thumb that has kept me going? Know at least two or three languages, so if one dies off, you have another one to fall back on while you train for a new technology.
  8. Support Junior - Assist and train the junior/entry-level developers on good programming guidelines and techniques. You never know...you may move up in rank and you'll feel more confident having personally trained and prepared them for their next position.
  9. Simplify the algorithm - Code like a fiend, but once you're done, go back through your code and optimize it. A little code improvement here and there will make support happier in the long run.
  10. Document your code - Whether its documenting a Web Service API or documenting a simple class, document as you go. I've been accused of over-commenting my code and that's something I'm proud of. It only takes a second to add an additional comment line for each 3 lines of code. If it's a harder technique to grasp, don't be afraid to over-comment. This is one problem most architects, backup coders, and support groups don't complain about if you've done your job right.
  11. Test, Test, Test - I'm a fan of Black Box Testing. When your routine is finished, your "stamp of approval" period starts. If you have a Quality Assurance department, you may be talking more to them than your project manager regarding errors in your code. If you don't test your code thoroughly, you may develop more than code. Possibly a bad reputation.
  12. Celebrate every success - I've met a lot of programmers who have conquered headache-style problems with a great programming technique and celebrated with a fellow programmer by doing the "shake", the high-five, or even a "happy dance." Everyone has enlightening periods in their life and even though that one happy coder asked you to come and see his extraordinary piece of code and you've seen that one piece of code over 100 times in your experiences, celebrate the success of a fellow developer for the 101-st time.
  13. Have Code Reviews Frequently - On projects and personally. In the company, you will always have code reviews of how well you coded something. Don't look at it as people crucifying your coding style. Think of it as constructive criticism. On the personal front, review your code and always ask, "How could I have done it better?" This will accelerate your learning and make you a better programmer.
  14. Reminisce about your code - There are two ways to looking at old code: "I can't believe I wrote this code" and "I can't believe I wrote this code." The first statement is often of disgust and wondering how you can improve it. You'd be surprised at how old code can be resurrected into a possible and better routine, or maybe even an entire product. The second statement is of amazement and achievement. Developers have their one or two project code achievements that they completed and had everyone standing up and taking notice. Again, based on your excellent coding ability, you could take those past routines or projects and update them into a better product or idea.
  15. Humor is necessary - In my 20 years of development, I have never met a programmer who hasn't had a decent sense of humor. Actually, in this industry, it's a requirement.
  16. Beware the know-it-all, possessive coder, and the inexperienced coder - Humble yourself when you meet these types of coders. The know-it-all tries to upstage you instead of working as a team player, the defensive coder created code that he doesn't want to share with anyone, and the inexperienced coder constantly asks for assistance every ten minutes where the finished code developed is yours, not theirs.
  17. No project is ever simple - I've been asked by friends, family, and associates to just "whip something up for me." To "whip" up a program or web site, it takes planning from both parties to complete something that both sides can appreciate. If someone needs a 3-page web site with Microsoft Access from the start, it winds up becoming a 15-page web site with SQL Server, a forum, and a custom CMS (Content Management System).
  18. Never take anything for granted - If you take on a simple project, you may think that a certain section will be easy to complete. Don't think that even for a moment. Unless you have a class, component, or piece of code already coded...and has been tested thoroughly...and is in production from an existing project, don't think it will be easy.
  19. Software is never finished - A fellow programmer once told me that software is never finished, it's "temporarily completed." Sound advice. If the client is still using a program you wrote and has stood the test of time, chances are, you are still updating it, which isn't a bad thing. It keeps you working. :-)
  20. Patience is definitely a virtue - When clients, friends, or family members use a PC, they get frustrated and proceed to hit a component of the PC or storm off. I keep telling everyone, "you are controlling the computer not the other way around." You need to have a certain level of patience for programming computers. As soon as programmers understand what they did wrong, they look at it from the computers point of view and say, "Oh, that's why it was doing that."

I hope this list of lessons learned have either inspired or provided a chuckle for some people.


Reference: http://www.dcs-media.com/Archive/20-20-top-20-programming-lessons-ive-learned-in-20-years-FI