Berk Ulsoy

Today I was looking for how to show only matching lines in vim and then I found myself looking up same thing for the others.

VIM:
g/SOMEPATTERN/

EMACS:
We have occur-mode for that. Just bind a key like this:

(global-set-key (kbd “C-c o”) ‘occur)

And then use it like “M-s o”  in search

Sublime Text 2:
There is a wonderful solution down with a nice python plugin:
http://superuser.com/questions/452189/how-can-i-filter-a-file-for-lines-containing-a-string-in-sublime-text-2 

I wonder how this can be achieved using Intellij Idea, Eclipse, TextMate 2, Notepad++ etc .. 

If you are not irritated by:

• Writing getters/setters and declaring types over and over
• Passing interfaces around and writing anonymous classes of them
• Generously using for/while loops and exiting them by breaking conditions
• Using reflection whenever you hit a wall
• Using hibernate or other relational mappers for all kinds of data access
• Writing code using an old version of some product just because it is the company standard which in fact seldom changes
• By the fact that not everything you interact is actually an object
• Not being able to quickly prototype or try things
• Writing long list of annotations
• Doing all communications based on SOAP and RMI
• Type casts and using things like instanceOf
• Thinking all data storage in pure relational model essentially
• Expecting the underlying data store, operating systems or network must magically perform lightning fast with their default settings regardless from what you tell them to do in your code
• Using whatever is traditionally welcomed in the company, instead of others that are even more useful
• Just adding more machines/cpu/ram whenever performance is an issue
• Avoiding implementation of things not because they are unfeasible but simply because they are not supported well within your preferred technology stack
• Throwing threads everywhere and put sleeps to slow down things
• Writing mandatory definitions in different places to achieve one thing
• Choosing to be the one who escalates rather than to be the one who actually solves
• Waiting for approval from the legal department for your choice of library/tool etc
• KISS is just a band for you

Then it is very likely that you are affected by a very traditional enterprise java environment. 

Meetings are very important. Not because they are useful but they are mostly evil. The sole purpose of a meeting is to get a result that can not be taken in another way reasonably. It is a weapon that mostly hits your own toe. It consumes everyones precious time and it should better worth for that. So, here are some rules that I like: (My main focus with those rules is internal meetings that are related to developers, QA, product life etc)
 

• Meeting should be held only if there is something that can not be discussed asynchronously via email/tracking system due to some very serious constraints
• No more than 4 people in the meeting. I have not seen a case where group of more people sit together and get some useful result. Limit the participants as much as possible. 
• Set the agenda well before the meeting and tell what do you expect from each individual so that they can prepare and you do not hear “oh, well. I have to look that one after the meeting” . Describe the purpose, required inputs and decision points.
• Use the white board.
• Never ever go off-topic, never let anyone do so. Stick to the agenda. Feel the danger when someone starts extending the discussion to somewhere else or someone says “since we are already here together, why don’t we …”
• Have a visual clock, timer etc that everybody can see. Just because everybody have their laptops and phones does not mean everybody will notice the time passing.
• Respect the end time. Start summarizing before the time is up.
• No fights should be tolerated. If the ball always stays between two, it is mostly waste of time.
• Always have conference bridge ready. Do not let anyone to have an excuse like not being at the office at the meeting time.
• Avoid overlapping with lunch time, early morning or late evening. May be this has been said thousands of time but early morning is the brightest time of the brain and it should not be wasted with meetings. During lunch time, nobody will have focus due to low sugar level. If it is going beyond work hours, frustration will increase. The exception is inter continental meetings that some people always sacrifice
• If the meeting is expected to be long and water sources are far in the office, it may be good to have water ready in the meeting room along with some candies. 
• If someone does not talk in the meeting, may be he/she is not needed at all.
• Send the meeting minutes right after the meeting. Clearly associate people with action points. Also, clearly write down decisions taken, optionally along with the name of the decision taker. 
• Think about the meeting after. What did go wrong ? Why did not you get the result you wanted ? How could you do it with less time ? Is it possible to do it with less people ? 

So this was a beginning of a new path. I am using Linux everyday since 1996 and it was my primary desktop environment since 2004. (Both work and home) However, I decided to switch to Mac OS X with an 13” MacBook Air.

Motivation points:

• Gnome3 was not enough anymore. They are getting rather slow to fix bugs and make improvements. There are numerous glitches that does not affect the life but make Gnome look and feel unprofessional. Unity is too simple for power user. Gnome2 is ugly, KDE4 is way too slow and Awesome WM is not useful with dynamic monitor setups and mobile business environments. Gnome3 shines as a modern desktop environment but it certainly needs a strong sponsorship and vision. 
   
• Need for a highly mobile laptop with very good screen. Ultrabooks were other options but getting max out of battery with 100% hibernation/sleep support is important. 
  
  
• File versioning support with ease of use (i.e Time Machine). I used btrfs in the past with snapshots but I was never happy with its performance I did not want to spend my time working with snaphosts since this is supposed to be a desktop environment. 

So far most of the things went well. I will describe what annoys me most, and the next post will most probably about setting up netatalk for Mountain Lion at home. Now you can continue here for the nasty things that you will face when moving to Mac OS X from Linux:

Read More →

• E-mail is difficult to categorize. Every user has to keep his/her own categorization system based on some personal criteria. Access to certain info should take same amount of time regardless from the user
   
• E-mail is lost. People delete mails. If they store e-mail locally, one day they lose it due to disk failure. Even if it is stored in server, one day user receives that his/her quota is about to overflow and needs to delete something 
  
  
• E-mail is difficult to prioritize. The first sender of an e-mail sets the priority. Then others may change it. Some can flag the topic and others may not. There is no guarantee of agreed priority for it.
  
  
• E-mail is diffcult to search and organize. E-mail clients (does not matter if it is web or desktop) does not understand a customer, due dates, projects etc .. They only understand keyword searches and headers. Those do not fit the logical entities of a business. 
   
• E-mail is difficult for setting communication standards. Using predefined keywords is a commonly practiced workaround to keep the mess under the carpet. People can be eduated to use project names in subjects or properly format messages. What will happen when the name changes ? Are you willing to educate every new employee ? There will always be someone forgetting the rules. How will you keep track ? Is it people’s responsibility to spend their time to keep those in line ?
  
  
• E-mail is not always open to all related people. Often, people prefer sending personal e-mails omitting the groups or other people. This is left unorganized and not recorded. The knowledge transfer between parties are kept as a secret to all other related people and future employees.
   
• E-mail is not always simple to manage in bad times. All e-mail systems have web interfaces. However consider yourself on a vacation and somehow you need to find something urgently. You were synchronizing your e-mail to your laptop but it is not with you. You found a pc and connected to your webmail. You noticed that the folders you have created were local ones so you can not access the content anymore. Busted ..
   
• E-mail is pain when returning from vacation. Many people have the problem of dealing with thousands of unread e-mails when they come back to the office. Most of the time, those e-mails are skipped quickly eventhough some of them may be very important, already overdue etc .. 
  
  
   

When you think on the subject, every business related communication can be categorized in to some project, department, product, customer etc … All of them can be part of a process. Process management is huge area to deal with. I will just focus on what I am interested, software development.

Instead of relying on e-mail for internal communication, try to eliminate it. How:

• Define your entities, like customers, projects, products, modules, people, requests etc.
• Search for an issue tracking system. You have lots of options. Jira, Redmine, Trac, Bugzilla and many others. Try to install a few of them in the beginning and see which one is more suitable for your needs. Extend them if you need (and if you can)
• Tell people that they are not supposed to send internal e-mails for business related activities unless certain privacy is strictly required. If someone says he/she has to send e-mail, listen for the problem faced. Tune your tracking system to support eliminate this.
• Strictly define the requirements to close an issue and enforce it technically if possible.  
• Think about all the reports that you can now generate out of this valuable data
  
   

In the end, you will find a well-defined and organized history of your company that employees can benefit equally without need to learn and comply mostly undocumented codex of “e-mail policies” ..

For some people, meetings are vital part of the business and for some people it is just a blocker, a stage to show off. Regardless of the perception, there a few common types of people you met in the meetings:

• Clueless : He has no idea about the topics that will be discussed. Somehow he mades himself to the cc list of the meeting request because otherwise he has nothing else to show that he is actually working
   
• Agenda Rapist :  He deliberately drives the discussion towards topics that he care. his job is easier when there is no capable moderator.
  
  
• Secretary : He does not contribute to discussions and just takes notes. He is usually assigned to distribute notes later on. So he is always found useful.
  
  
• Defender of the Universe : His sole purpose is to get as minimum action points as possible for himself, or for his department. 
  
  
• Striker :  Motivation is similar to the defender of the universe. But he also needs some tasks done for him and he aggressively tries to make them assigned to other people.
   
• Iron Fist : The meeting room is his arena and he so aggresively moderates everything in it that people feel first asking him before going to pee.
  
  
• The Technical Guy : Usually dragged to meetings by his manager to cover some ass. He usually looks bored and dreams about going back to his office.
  
  
•  Shy / Naive Guy : He can not defend himself well and he tries to be positive in every direction. In the end, he finds himself bitchslapped for the mistakes that he is not even responsible and assigned unrelated tasks.
   
• Selfish Guy :He is almost always superior in the hierarchy as well. He can come late, leave early, talk whatever he like, or reschedule the meeting in the last minute without asking people.
   
• Crowd Freak : He thinks that the best meeting is the most crowded one. So puts everybody in cc list and always includes all managers so that he can show more people simultaneously that he is working very hard.

Are they familiar to you ? What others do you have ?

All Linux distributions have their own package management and their main goal is to provide stable, secure and working software to end users. 

This almost always works well .. Almost .. Unless you are a Java developer who needs many libraries and different server softwares.

The added value by package maintainers becomes ultimately useless. Because:

• Java ecosystem is only loosely connected to the underlying operating system and its traditions. Operating system is no more than a container. There is no gain to obey standards of the host system.
•  Most of the time, people prefer to have all Java stuff under same directory, which is irrelevant to other host files, like /opt .. 
• Developers follow the release of new versions so closely that package maintainers can not update fast enough. Plus, package repositories include only a small subset of all available libraries
• Developers use multiple versions of libraries in different modules. Package managers by default present you the latest version. Build tools are just simpler to work this way.
• In most places dependencies, installation, deployment etc are also managed by Maven/Ant or sbt in case of Scala without relying on anything else. 
• In many places, developers use combination of Linux, Windows, OSX machines that also rely on build management tools, not OS packages.
• Continuous integration systems also work with build management tools and they also don’t care about packages provided by distribution.

Efficiency, ease of use, flexibility and general availability of native build tools make distribution packages useless for most businesses. So, why do distributions spend huge amount of effort on this eventhough it is just not possible to make people’s life better ? When did you last use deb packages of Spring framework rather than just defining them in your pom file ?
 

There is not much application software like Emacs that has roots from decades ago and still regarded as one of the best, if not the best. That well deserved fame leads many developers to use it for Java. What I will repeat after James Gosling is, “just don’t”. As your project scope widens, you will be tackled more by the missing features.

First of all, Emacs does not understand the language by itself. It is a very powerful editor environment but it relies on addons to behave as you wish. These addons know the language and try to understand what you are doing. They basically tell Emacs what to do. So the editors capability to be powerful IDE, becomes limited to the capability of the addon. 

Currently there two reasonable addons to develop Java on Emacs:

1. JDEE:

• The most feature rich Emacs addon. However, the development status is almost frozen. Debian has no package in unstable and testing anymore. Mailing list activity is very low. Even the official website still refers to Sun as the trademark owner of Java.
• It relies on BeanShell to understand what you are trying to do. BeanShell is a dead project which does not even support Java 5.
• malabar-mode:

• Developed by Espen Wiborg after some frustration due to JDEE. Though it is much better and modern than JDEE (support for Groovy console, unit tests, maven etc) it still lacks the the important points that I will describe. Plus, Espen has no time to maintain anymore and he is using Intellij IDEA for himself.

Before getting crucified, I would like to tell what you will miss when using those two:

• Perfect code navigation: As I mentioned, Emacs does not understand what you are trying to do. Java IDEs on the contrary, does well. They understand what an interface, inheritance, EJB, annotation, xyz framework, exception etc is .. They can correctly guide you in all those features and frameworks.
   
• Better refactoring: Since Java IDEs undertand the language, they can provide much detailed refactoring options. Note that eventhough refactoring is a text replacement and file operation, the editor should be able to understand the language constructs to be able to provide more options.
   
• Integration with crucials like maven, application servers, frameworks etc: 
   
• Better debugging: Java IDEs provide better debugging interfaces with multiple windows, easy runtime evaluations with code complete in all those runtime operations. 
   
• Better diff: Helpers in diff windows are easier to use because visualization of them are better. When it comess to a diff, visualization is the most important thing to be able to navigate and find what you are looking for  
   
• Multithreaded editor: Emacs is a single process that communicates with external tools but Java IDEs are multithreaded UI applications that all threads works harmonously. So the editor can check your typing, do suggestions, see if any files changes, update maven dependencies, colorize, notify you about updates from ticket system etc.
   
• Intentions and inspections: You may know the language well. You may know many frameworks as well. But unless you are extremely knowledgable in all those you use, you will write suboptimal code that may even end up faults. Intentions are simple but effective fixes to code like importing a class static instead of inline access. Inspections are suggestions from IDE so that you will be saved from mostly runtime issues like ineffective comparisons, mission serialization version in a serializable class and many more
   
• SCM visualization: There is nothing wrong with command line scm tools but sometimes GUI versions are more useful and time saving, especially when you need visualization of branching history of a complex tree
   
• Group reviews: It is not difficult to setup collaborative code editing with Emacs, but the things that you will mostly need are already there with less effort. With those features, peers can just see each others versions, work on the same file, diff them, talk with each other.

These features are very important time savers when you are working in projects with tens of different maven modules, few heavy frameworks, tens of thousands of lines. 

Still, there are things that I miss a lot from Emacs. The most important one is to be able to easily define a new command and keystrokes for my own needs. Java IDEs support Emacs keymap and they let users assign keys for all functions accessible from GUI. However, you can not easily define a keystroke so that -for example- the editor will search only the files in test scope with class names starting Mock*. (I don’t find macros easy enough) So eventhough virtually all functions are accessible from keyboard, there will always be some need to use mouse, unfortunately. 

The next is the contrast color themes that make my eyes happy. Java IDEs have various contrast themes but they are never as complete as Emacs alternatives. (As an example, consider that the code window is colored but a some popups or windows are still grey/white. Terrible experience ..)

This is written by a long time Emacs user who still uses Emacs for things other Java/Scala. For the latter, I prefer Intellij IDEA.