Chad Fowler, in his book, My Job Went to India, made the following remarks about working effectively:
If you treat your projects like a race, you’ll get to the end a lot faster than if you treat them like a prison cell.
A sense of urgency, even if manufactured, is enough to easily double or triple your productivity.
I’d add that it needs to be an enjoyable race, and that urgency, sustained for too long, can wear a person out. Races are more enjoyable when run with a group of friends.
On the back of my mind for the past few years, I've been thinking about how I.T. security becomes less meaningful as time goes on. The use of digital cameras isn't usually allowed, yet a company isn't (usually) going to boot out an employee for having a cell phone with a digital camera -- or even using it to take a snapshot of a diagram that will be placed on a corporate wiki. The use of USB thumb drives for transferring and storing corporate data is perceived as a risk, but often, it's a practical way of getting one's job done. Remember network firewalls? They're still in place, but they're increasingly meaningless. They certainly don't keep out viruses and trojan horses. And with the increasing prevalence of wireless networking, there's even less incentive for people to play by the I.T. security rules. Dan Kaminsky expresses these thoughts better than I have :
... every restriction, every alteration [I.T. makes] in people's day to day business, carries with it a risk that users will abandon the corporate network entirely, going "off-grid" in search of a more open and more useful operating environment. You might scoff, and think people would get fired for this stuff, but you know what people really get fired for? Missing their numbers.
Its never been easier to get away with going off-grid. Widespread availability of WiMax and 3G networks mean there's an alternate, unmonitored high speed network available at every desk.
Kaminsky goes on to discuss some of the ramifications of these ongoing changes, including "the Cloud" (e.g. Google docs) and the security of corporate data.
I needed to profile a Java application, and since we had a JProfiler floating license, I used it. JProfiler works well, although it's pricey. I was googling for other Java profiling tools, and stackoverflow.com made mention of jvisualvm, which comes bundled with JDK 6 release 7. I noticed that on my Fedora 10 box, the java-1.6.0-openjdk package includes jvisualvm. None of my coworkers had heard of it.
JProfiler introduces a significant performance penalty into the code it profiles, whereas other tools including jvisualvm and YourKit have a much lower impact. I'm going to give jvisualvm a try, once I get the target environment set up properly with the new JDK.
UPDATE: jvisualvm won't profile remote applications like JProfiler can. jvisualvm is not quite as easy to use, and I haven't figured out how to get stack traces on the CPU and memory hot spots. Overall, I like the tool.
UPDATE 2: jvisualvm can be configured to give a stack trace of memory hot spots. I've learned that performance between the Java 1.5 and 1.6 jvms can be very different. I've learned that I can run 'kill -3
Have you considered the merits and applicability of RESTful web apps? Here are a few notes I’ve made.
There was quite a discussion about RPC, REST, and message queuing — they are not the same thing. Each one is needed in a different scenario. All are used in building distributed systems.
Wikipedia’s explanation of REST is quite informative, especially their examples of RPC versus REST.
The poster “soabloke” says RPC “Promotes tightly coupled systems which are difficult to scale and maintain. Other abstractions have been more successful in building distributed systems. One such abstraction is message queueing where systems communicate with each other by passing messages through a distributed queue. REST is another completely different abstraction based around the concept of a ‘Resource’. Message queuing can be used to simulate RPC-type calls (request/reply) and REST might commonly use a request/reply protocol (HTTP) but they are fundamentally different from RPC as most people conceive it. “
The REST FAQ says, “Most applications that self-identify as using “RPC” do not conform to the REST. In particular, most use a single URL to represent the end-point (dispatch point) instead of using a multitude of URLs representing every interesting data object. Then they hide their data objects behind method calls and parameters, making them unavailable to applications built of the Web. REST-based services give addresses to every useful data object and use the resources themselves as the targets for method calls (typically using HTTP methods)… REST is incompatible with ‘end-point’ RPC. Either you address data objects (REST) or you don’t.”
RPC: Remote Procedure Call assumes that people agree on what kinds of procedures they would like to do. RPC is about algorithms, code, etc. that operate on data, rather than about the data itself. Usually fast. Usually binary encoded. Okay for software designed and consumed by a single vendor.
REST: All data is addressed using URLs, and is encoded using a standard MIME type. Data that is made up of other data would simply have URLs pointing to the other data. Assumes that people won’t agree on what they want to do with data, so they let people get the data, and act on it independently, without agreeing on procedures.
There’s an impressively in-depth presentation from OSCON 2008 about Practical Test Driven Development in Perl. It covers Test::More, Test::Class, Test::Differences, Test::Deep and Test::MockObject.
I also found the following to be interesting: Even Faster Web Sites and Pro PostgreSQL. Reading these helps me to know a little bit about what I don’t know.
When attempting to find and fix performance bottlenecks on a Linux system, it’s helpful to know where to start. Here are a few resources I’ve found:
IBM’s Linux Performance and Tuning Guidelines, published July 2007
This IBM Redpaper describes the methods you can use to tune Linux, tools that you can use to monitor and analyze server performance, and key tuning parameters for specific server applications. The purpose of this redpaper is to understand, analyze, and tune the Linux operating system to yield superior performance for any type of application you plan to run on these systems. ( Read more… )
This website has useful tips: http://www.performancewiki.com/
Google has some tools that people recommend: http://code.google.com/p/google-perftools/wiki/GooglePerformanceTools
This book seems to be recommended: Optimizing Linux Performance
In my experience, strace and ltrace along with the “-c” and “-T” options, are extremely useful — even for Perl scripts. The “-T” option shows the timings of calls, and can help isolate what calls are the slowest.
strace -o program.trace -T -p <pid>ltrace -o program.trace -T -p <pid>The “-c” option gives a summary of the calls that used the most time:
strace -c -p <pid>ltrace -c -p <pid>I haven’t found a good way to isolate memory leaks in Perl programs — not that I’m an expert. What has worked for me is to divide and conquer in order to isolate the problem.
I work on source code from two separate SVN repositories. One of them is geographically remote. Working with the remote server is slow for ‘log’, ‘diff -r’, ‘blame’, etc. Due to my interest in distributed version control, and my desire for faster repository access, I decided to try git and git-svn. Doing ‘log’, ‘diff’, etc. with a local git repo is much faster, but on the whole, working in a git repo created with git-svn has been difficult and unrewarding. Perhaps it would be easier if others at my company were using git-svn and we could share ideas. Working with git and git-svn requires learning a new workflow, and I haven’t yet reached enlightenment.
Challenges with Git:
Challenges with Git-SVN: (More complicated to use than Subversion)
Reasons to continue with Subversion:
I hope that in a year, Git, git-svn and developer tool integration will be more mature and thus rewarding to use. With the rapid development I see happening, it wouldn’t be surprising.
I will continue to use git-svn. It gives me the speed I need for working with log history, annotate and diff.
Update: I’ve come across Git for Computer Scientists, and seeing the pretty graphs leads me to believe that working with git requires an understanding of how git works.
Business ethics about survival, leaders told
Ethics aren't important because they help businesses feel good about themselves... [it] is about staying in business.
"We don't ask you to do ethics so you can feel warm and soft and squishy," Jennings said. "We ask you to do ethics because it is an integral part of long-term business survival. This is the thing you have to stay focused on when the pressure hits. This is the antidote," [said professor and columnist Marianne Jennings]
mtnwestruby: Chad Fowler Keynote
16 March 2007
Background: Musician. Dropped out of music school to be a programmer.
Programming experience: Perl. Java Enterprise software. Now Ruby.
He's been organizing international Ruby conferences since 2000, even before he could write a decent Ruby program.
Ruby is at a dangerous crossroads. We need to act, as a community, to avoid failure. How do we need to behave to remain relevant in the industry -- as programmers, and as a Ruby community? For so long, Ruby has been perceived as a niche player. The community has been in the habit of fighting, and defending against FUD. Once we start "winning", we continue those habits, and new "converts" to Ruby pickup the same habits. We hear "Ruby doesn't perform well", and we should say "not it doesn't". We hear "Ruby doesn't support internationalization", and we should say "no, it doesn't".
If you're at this conference, you're a pioneer in the dynamic languages community. In 2001, Matz was the only professional Ruby developer. In 2005, that had changed because more people were employed to write Ruby code. We're "winning" in the sense that we can use Ruby in the workplace. Sun and Microsoft are hiring people to work on Ruby.
Ruby 2.0 has been vaporware for longer than Perl 6.
The Ruby community of 2006 and 2007 is a melting pot of backgrounds -- PHP, .NET, ASP, 4th Dimension, J2EE, Rails, system admins, the agile community. The tendency is to take a big community and to run it like a big company. The germs (PHP programmers) are going to start coming into the community, and the antibodies are going to start smashing them. There are some germs in the community that do need to be cleansed. We need to figure out what those germs are, although some germs we will never get rid of.
There are germs we must be exposed to in order to keep the community strong.
Metaphors influence the way we think about things. Americans think "arguing is war", and that shapes the way we respond to people in the community. However, not all cultures have that metaphor.
The book "Leading Revolution" by Gary Hamel is worth reading. It has nothing to do with programming. Things designed in Ivory Towers don't respond well to small evolutionary changes.
If we're trying to grow as a community, creating a new framework like Rails is a waste of time -- there are more interesting problems to solve.
We build systems to support people, and sometimes, geeks forget this fact, and become jerks.
Monkeys in India are brave and annoying when they're trying to steal food. In Southern India, they're controlled by creating holes in the ground, with a larger space at the bottom. The hole is just big enough for the monkey to slip his hand into, with food at the bottom in the bigger space. The monkey wants the food, and puts his hand in. Once he makes a fist by grabbing the food, he can't pull it out. Someone comes along and clubs the monkey. The monkey doesn't let go of the food because of value rigidity.
In the Ruby community, Chad hopes we are not like the monkey. We need to at least be cognizant of the rigid values we have, and whether they're worth holding onto. Do you identify yourself as a Ruby developer? Hopefully, you are always reaching for something beyond what you are comfortable with -- perhaps it's Erlang, Haskell, ocaml, etc. If you're comfortable, if you know the answers, you aren't learning. Try to lead, but also try to be learning something new.
Chad has done well in the Ruby community by doing the things that no one else wants to do -- organizing Ruby conferences, bringing publicity to Ruby gems.
Lately, I've been developing on Linux. When developing remotely, I can get along with a shell and vim, with VNC, or with remote-X. However, none of these options are as fast or as nice as using NX. Here are the instructions to install and use the NX server and client on Fedora Core 5 and 6: http://fedoranews.org/contributors/rick_stout/freenx/
What's the best C++ IDE in Linux? Out of the three IDEs I have evaluated, I'd recommend either SlickEdit or NetBeans C++. I haven't tried Emacs. I've installed KDevelop, but haven't tried it much yet.
Overall: Immature and over complicated. I prefer vim with a ctags file, jedit, nedit, or gedit. Code Completion: Broken -- rarely works Search by Symbol or Reference: Broken Debugger support: Yes. Ugly user interface Custom build (bjam): Yes Project support: Yes. Automatically adds new files, removes old files from workspace Refactoring support: No Subversion support: Yes, with plugin
Overall: Excellent IDE Code Completion: The best of the bunch, but not as good as Visual Studio Search by Symbol or Reference: Excellent Debugger support: Yes. Difficult to setup Custom build (bjam): Yes Project support: Yes Refactoring support: Good Subversion support: Yes Notes: Has fairly good key emulation support for Visual Studio, Vim, Brief, Emacs, etc. Language Support: Tagging and syntax highlighting for C++, Java, Perl, Python and Ruby (to name just a few).
Overall: Better than Eclipse CDT Code Completion: Yes Search by Symbol or Reference: Yes Debugger support: Yes, but haven't yet figured out how to set breakpoints. Custom build (bjam): Yes Project support: Not yet evaluated Refactoring support: No Subversion support: Yes, with plugin or with NetBeans beta 6.0.KDevelop
Overall: Not yet evaluated Code Completion: Yes Search by Symbol or Reference: Symbol - Yes (using ctags); Reference - Unknown. Debugger support: Yes Custom build (bjam): Most likely Project support: Yes Refactoring support: Unknown Subversion support: Yes
None of these tools are as good at code completion as Microsoft Visual Studio 2005.