This is a quote-of-aquote I found in quora. It is the absolute most practical advice
I have read in my life about how to go about finding your passion.
I have found that I have always gone out of my way in life, to do that which excites
me the most, even if that has meant making my life 'harder' from an outsider's perspective,
so this advice really resonates with me.
Some of the worst things that have happened to me in my life, have been because of me following my
passion, but also, the absolute best achievements in my life have been due to me following my passion.
So I would never change any of my decisions, because now that I look at it that way, all of those
decisions are what have led me closer and closer to my true passion, and I say closer, because I still
have a feeling that I have not found my ultimate passion, and may never will...
In the meantime, I'll just keep looking.
My thesis project is about automatic evaluation of object-oriented design by means of automated code analysis; in other words evaluate the design of a program automatically.
I found the need for a tool that would allow to me to extract the code model from a program and then query over that model in order to extract information and metrics about the program's design.
The characteristics I was looking for in a code analysis tool where:
The code model extractor must process source code or intermediary code Java or .Net
Rationale: If we are able to analyze bytecode or MSIL we can use the same tool for any language of the given platform.
Acceptance Criteria: A proof of concept must be implemented that is able to extract the code model in the form of objects of the given platform.
It must possible to invoke the tool from within the code as objects, without having to go through a GUI or CLI.
Rationale: This is to easily integrate the tools as part of another project without hassle or strange behavior (i.e. opening a GUI, etc)
Acceptance Criteria: A proof of concept must be created that invokes the tool in a programmatic manner without using the CLI.
It must be able to provide:
- Number of lines of code in a method, class or namespace (package).
- Method calls between classes
- Location of method calls between classes
- Method and member signatures of a class
- Enumeration of classes, abstract classes and interfaces
Rationale: This features are needed in order to perform the code analysis, because that will provide the data we will measure and evaluate. With those features it is possible to obtain all the Chidamber & Kemerer metric suite which are fundamental for code analysis.
Acceptance Criteria: A proof of concept that can obtain each and one of the listed items programmatically.
The extracted code model must be readable in-memory, directly or indirectly.
- It is allowed for the tool to generate a file first and then read that file to generate an in-memory model
Rationale: The code model must be representable in-memory in order to use for automatic evaluation.
Acceptance Criteria: A proof of concept must be created where the code model is fully representable in memory.
This post is primarily to remind me of the concepts behind Extreme Programming. This post will help me remember that Extreme Programming is not just pair programming, TDD, reduced documentation, evolutionary design and reduced planning.
XP practices are actually the smallest piece in the puzzle, the guiding values and principles are what made Kent Beck come up with those practices.
(Human) Values => (Domain Specific) Principles => (Software Specific) Practices
Values of Extreme Programming
Values are intended to balance and support each other. Improving communication helps achieve simplicity by eliminating unneeded or deferrable requirements from today's concerns.
Values do not provide concrete advice about what to do in software development. Because of the distance between values and practices, for that Principles bridge the gap between them.
- Communication is important for creating a sense of team and effective cooperation.
- The objective of communication is to transfer knowledge and information between the team(s).
- Simplicity is the most intensely intellectual of the XP values.
- The objectives are to make a system simple enough to gracefully solve only today's problem and eliminate the waste of unnecessary complexity.
- It is also important to remember that simplicity is contextual, the design must be understandable by the team working on it, otherwise it is pointless.
- Change is inevitable in software development, therefore an XP team embraces change by giving high value to feedback.
- XP teams strive to generate as much feedback as they can handle as quickly as possible.
- They try to shorten the feedback cycle to minutes or hours instead of weeks or months. The sooner you know, the sooner you can adapt.
- Courage is effective action in the face of fear.
- Doing something without regard for the consequences is not effective teamwork.
- Courage alone is dangerous, in concert with other values it is powerful.
- Examples: The courage to speak truths, to discard failing solutions and to seek new ones.
- The other four values point to one that lies below the surface: respect.
- The contributions of each person on the team need to be respected. I am important and so are you.
- Every person whose life is touched by software development has equal values as a human being.
- Your organization, your team, and you yourself may choose other values. What is most important is aligning team behavior to team values.
This is quick post to inform people how to get zoom in and out of text in eclipse, since alot of coders want it, but it is not easily found.
Well, here is your holy grail: There is a project from a guy called 'tarlog' that made a plugin for eclipse at this, you can find information about it in this StackOverflow question.
It has some other features for eclipse, amongst which is Ctrl++ and Ctrl+- to change the font size, it's frickin' awesome.
Many times, you need custom resources for your test projects, and these resources might be needed in several test projects.
Now, you could simply copy all of these resources (files) to all your projects and 'include them' in the .csproj file, but you know this would break DRY principle, which is a good idea to abide to.
Anyway, normally if you want to copy a resource to the output directory you do this:
<Target Name="CopyResources" DependsOnTargets="Build">
<Exec Command="CALL ..\my\resources\generator.bat $(OutputPath)" />
Note: I am assuming you have a script that generates resources and then puts them on a path you give it.
When you build your solution in your computer and execute the tests with some of the major test runners, it might work, but not with all of them; and it might fail in some cloud hosted environments, like for example AppHarbor.
The solution is simple, instead of using
$(OutDir), and this will work in local and hosted environments.
<Target Name="CopyResources" DependsOnTargets="Build">
<Exec Command="CALL ..\my\resources\generator.bat $(OutDir)" />