Being a technically savvy person is great for fixing things and playing with technology. Earning a living doing technical things is a lot harder. There are many aspects to being a professional ranging from simply communication style going through personal marketing and right down to the core ethics.
This is from a place I worked at. It is a really great idea so I have summarized it here in case some other place wishes to implement a similar procedure. The original work was done by a really great guy named Marc Wensauer (http://www.linkedin.com/in/marcwensauer).
A mechanism to provide an indication to a user that he or she has left a system unattended with an unprotected, active user interface.
The act of duding is not malicious, recognize that the fault lies with the person that failed to lock the system and not with the person duding the system. The act of duding is an accepted part of company culture and one of the fun aspects of working at this company. A person with malicious intent would not send a dude message to the Fun distribution list but would do something harmful instead, possibly without even being detected. The person that failed to lock the system should take the duding as a friendly and good-natured reminder to be more attentive.
MSG1: To: Fun Subject: [Dd]ude!
MSG2 <reply all>: To: <MSG1 Sender>; Fun Subject: RE: [Dd]ude!* Sweet!
Work groups and teams have the right to prohibit execution of the dude protocol by other group/team members within the confines of a shared space.
The prohibition does not extend to non-group/team members. As that would indicate that it is acceptable to leave a system unlocked while shared space is occupied by group members if such a prohibition is in effect. However, protection of systems in the shared space is the responsibility of all team members. A non-team member is allowed to execute the Dude Protocol on systems in unoccupied shared spaces. The Dude Protocol may be executed even if the shared space is occupied if the team members are not paying attention to unlocked system(s). If a team member tells someone to stop the Dude Protocol may not be executed any way.
Individuals executing the Dude Protocol should not use the system to do anything other than executing the the Dude Protocol (e.g. do not read other emails, look at or post to web pages, look at browser history, look at or use other running applications, open or copy files, etc.). In short, do not intrude on someone's privacy or compromise their system.
Any individual executing the Dude Protocol is required to follow through and lock the system after sending the Dude email.
If caught while Duding someone, stop immediately if you are asked to stop, otherwise you are inviting escalation. Likewise, when catching someone Duding, do not engage in behavior that can be interpreted as physically threatening.
http://www.imdb.com/title/tt0242423/ Dude, Where's My Car?
http://www.hulu.com/watch/12169/dude-wheres-my-car-dude-sweet dude sweet clip
http://dilbert.com/strips/comic/2008-12-07/ Dilbert has an anti-dude device
In preparing for a presentation on Behavior Driven Development I needed some examples. So I started searching the Internet for exemplar problems to demonstrate various techniques. In the process I instantly got hooked on the idea of regularly grabbing some programming challenge to hone my programming skills. The goal is to find lists of small challenges that should only take a few hours to solve but for which I can apply rigorous standards such as BDD, Continuous Integration, Design By Contract, and other best practices.
It would be good if some example answers were provided with explainations and possibly discussions of the solutions.
Standing there asking people for money is not an easy thing to do. Even more important is figuring out how much to charge. A lot of people feel guilty and charge far less then they should. Further you always feel like "man if I charge more I wont get hired." Well take it from me there is an upper limit, but it is higher then you probably think. I have personally seen consultants with only a few years experience charge $250 / hour and get large contracts, while really smart people charging only $50 / hour are always on the verge of starving.
So what is a fair rate for full-time consultants? Well there is a pretty simple standard formula for hourly rate which is "(current annual salary * 2) / 1000".
Then number break down like this.
Some people feel these are a waste of time. I still ask them because they are cheap to ask and help me judge the applicant's personality and cultural fit with my team. Certainly, I have been shocked at how many highly experienced developers cannot answer any of these questions!
DeMarco and Lister, in their classic Peopleware book, recommend holding Interview Auditions. In the audition, the candidate gives a fifteen minute presentation on some aspect of their past work to an audience consisting of all the applicant's future co-workers. This helps ensure new hires are a good cultural fit with the team. Moreover, allowing all team members a say in whether to hire or not helps build team spirit and cohesion.
I've never asked any of these but am toying with doing so. The idea is to play out a scenario with the interviewee to see how he reacts in inter-personal relationships in various (e.g. stressful) scenarios. Has anybody tried doing this? How did it go?
== Generic Expected Layout ==
Many shops adopt a source layout similar to this layout.
The root level is used as a dumping ground for all the code in the organization usually with the names broken into modules (if necessary) and each module has directories for build, distribution, source and test artifacts. The source and test directories are further subdivided by artifact type, in this case config, java, resources and sql.
*; src : Source artifacts related to the module
*; test : Test artifacts for the module
*; config : Module configuration
*; resources : Other source files.
*; sql : SQL scripts
== Jakarta Layout ==
Jakarta projects have adopted a common directory layout with the following elements:
* project root
*; bin : common binaries and scripts
*; build : location of build output
*; dist : location of distribution output
*; doc : project documentation
*; lib : various java libraries (e.g. junit, log4j, etc)
*; src : location of java source code
The bin, lib, doc and src directories would be under source control, build and dist are generated by the build tool. Other source content, like descriptors and jsp files would also be placed under the 'src' hierarchy. The focus being on keeping all source material together rather than mimicking the deployment hierarchy. Sub-projects would each have their own copy of the tree.
More information can be found at http://ant.apache.org/ant_in_anger.html.
== Sun Blueprint Layout ==
The Sun suggested guidelines are described at http://java.sun.com/blueprints/code/projectconventions.html . Their document is full of details - below are some of the interesting highlights:
; apps/ : Base directory for applications
; build/ : Created by build tool to hold build output
; components/ : Shared components used by more than one application
; conf/ : Configuration or other set-up files
; dist/ : Created by build tool to hold unzipped versions of the binary project artifacts
; docs/ : All project documentation
; lib/ : External libraries
; web/ : Static web content
; setup/ : Files used to configure the application environment, e.g. SQL scripts
; test/ : The top-level test directory contains project integration tests. Each individual component should also include unit tests under src/test
== Tuscany / SCA ==
Tuscany (http://incubator.apache.org/tuscany/index.html) is an Apache incubator project focused on building an SCA (http://www-128.ibm.com/developerworks/library/specification/ws-sca/) container. The current release contains sample SCA applications (download from http://incubator.apache.org/tuscany/download.html) which are mildly interesting since they provide a dual Ant/Maven build. Here's a sample application directory structure:
*; src : Project source files
*; main : Main application source files
*; test : Application test source files
*; java : Java class sources
*; resources : Metadata files
*; webapp : Web application archive files.
== Maven Layout ==
The standard Maven layout is considered an industry best practice now:
my-app |-- pom.xml `-- src |-- main | |-- filters | | `-- filters.properties | |-- java | | `-- com | | `-- mycompany | | `-- app | | `-- App.java | `-- resources | `-- META-INF | `-- application.properties |-- site | |-- apt | | |-- format.apt | | `-- index.apt | |-- fml | | `-- faq.fml | |-- fr | | |-- apt | | | |-- format.apt | | | `-- index.apt | | |-- fml | | | `-- faq.fml | | `-- xdoc | | `-- xdoc.xml | |-- site.xml | |-- site_fr.xml | `-- xdoc | `-- xdoc.xml `-- test |-- java | `-- com | `-- mycompany | `-- app | `-- AppTest.java `-- resources `-- test.properties
This structure is described in the Maven Introduction to the Standard Directory Layout (http://maven.apache.org/guides/introduction/introduction-to-the-standard...):
; src/main/java : Application/Library sources
; src/main/resources : Application/Library sources
; src/main/filters : Resource filter files - used for property substitution at build time
; src/main/assembly : Assembly descriptors
; src/main/config : Configuration files
; src/main/webapp : Web application sources
; src/test/java : Test sources
; src/test/resources : Test resources
; src/test/filters : Test resource filter files
; src/site : Site - the Maven-built project website (details at http://maven.apache.org/guides/mini/guide-site.html).
Build output is placed in a target directory at the top level. Much like the Jakarta standard, if a project has multiple subprojects then each subproject would live in a directory under the main project with its own src directory.