IDE

Intro

An IDE (Integrated Development Environment) is a programming environment that integrates applications. While MS has visual studio/.NET Unix uses tools in tool chains to create an IDE.

I have put together open source tools that I use and perhaps glued them together with scripts.

A continuous integration implementation which creates and manages makefiles was implemented.

List of Software Used in the IDE

• Vim, gvim. Can tailor for example I set spell check to be permanently on. Also highlight.
• gcc on Linux, Mac, Cygwin, MingGW. OpenGL for graphics.
• Bash - for scripting
• Subversion for version control. Incredibly important for managing files. Have the gvim editor do svn diffs.
• gdb debugger. ddd for Gui front end. While I believe ddd is not as powerful or user friendly as MS Visual Studio, I found ddd to be extremely effective by writing debug code and printing to the terminal, getting a feel where it becomes buggy as it is dependent on gdb.
• mkerrors and mkupdate which compile and generate the makefile respectively.
• Doxygen for in source documentation.

This IDE is for a C++ programming environment in Unix. And the truth is that the tools are generally tools that other people write and are free.
e.g. the editor is gvim though BBEdit, emacs ... could be used.
Debugger is gdb with a ddd front end. I use gcc compiler. svn server for version control. Firefox browser. Bash script language - to access the power of the OS.

This is not an IDE that answers all your questions, it is an IDE where you can put anything into the tool chain.

Principally I implemented a makefile build tool with assumptions of a flat directory structure and the main C++ program named main.cpp . Thrown in unit testing and feedback through html display.

I have not implemented dependency triggers because make and the programmer do an excellent job.

You could compile with profile options and then compile with other options and this will not be detected. Similarly I do not compare unit test and compile time date stamps. This is more like a car with gears than an automatic. Such warnings could be put in at a later point in time, particularly with a GUI implementation, but as is this has been wonderful for scalability and handling makefile issues.

Goals

• A major point of an IDE is to scale up. Continuous Integtration realizes this. When software grows its complexity generally increases. Usually through dependencies. This IDE currently handles around 120 thousand lines of code, but should scale up to a million. [with not much effort indexing of files would scale this to millions, and while I restricted the directory structure to a flat file structure enforcing simplicity this restriction could be removed]
• Tools to support programming environment.
• Evolve as a programmer and change. While I focus a lot on implementations and technical things, I do this to pursue my dreams. OO, algorithms, maths and a drive to change how people think.

Continuous Integration

The goal is to get the workspace to the point where Continuous Integration is taking place. i.e. a "current" build for testing, demo, or release purposes.

A framework for managing the workspace has been implemented to meet the goal of continuous integration.

Previously I was managing the dependencies by hand but encountered many problems in maintaining dependencies.

I investigated and implemented automated build and testing tools, and Extreme Programming principles which were suited to my development.

Therefore I have implemented the framework for automated build and testing in this code base. proj/ide/testscripts.sh provide tools at the command line for compiling and testing the workspace as a whole, or as modules with their units. See CI Unit Testing.

The main point of continuous integration is when a change is made in one part of the code that effects another the dependency can be addressed.

CI allows you to take risks and be confident, hence you can write more full on software that is outside the square.

[ After arguing with military software engineers who write dumb/simple yet error free code(their goal) I realized that without something full on their way will prevail, it likely will but at least the potential for creative code is more closely realized. They appear reluctant to enter original/dynamic design and claim that it must be engineered on paper before implementation. The problem with this perspective is that most designs usually start from prototypes and incrementally develop. ]

[ In short I do not know the future before I code. It takes time before ideas evolve. My parser has an iterator concept that eventually included scope. Combined unit testing and imagining the software produced the pattern which worked, yet the software engineer would reject it as rubbish and instead use an entirely differently engineered software model for equivalent effect. This is an argument about interfaces and the conservative approach and common practises are ridiculous. The KISS principle can equally be applied to data in interfaces so they use such arguments in emotive rather than logical fashion. ]

[ Since CI supports better testing you do not have to be this restrictive to get good software and software that lives depend on. The potential to decouple the issues exists. Further C++ language extensions could make many more coding designs possible. I am often thinking I would like to do this/that in what is almost a trivial piece of code but the language forbids it. Hopefully templates will be extended for more primitive substitution like macros with type safety which would give C++ a kick, the standard C++ is extremely conservative in this direction and the committee deserves criticism. ]

• Testing outside of unit testing:
  One way: The programmer needs to write programs to test programs. Even threading issues can be reproduced. When this is not possible (just too hard given constraints) document what you did.
  e.g. set breakpoints in VS to reproduce threading issue ...
• CI and source control
  CI is directly linked with source control. I believe having individual computers as the source control server is better than central control source control. Git should be recognized as Continuous Integration.
• CI should support branching. The idea of continually checking in source is not necessary for the world, but necessary for the developer. The developer has their own branch and their own CI state. This can then be merged with main branch. At times you need to work separately from the main branch when doing non-trivial things.
• CI practised before defined.
• Engineering separate from software design. I further believe in engineering software that is outside standard practises. For example writing classes without encapsulating as OO does not require encapsulation. CI is critical for this because it tests the software. The more extreme your requirements the more CI supports this.
• References:
  Fowler: Continuous Integration (original version)   Continuous Integration
  Continuous Integration: Was Fowler Wrong?
• Email and patching can be used in large scale software integration. CI needs to optionally include this.

Composition

Documentation has a working diagram of the IDE.

proj/ide/ide.sh puts the pieces together to build the IDE. (Excluding unix itself which is also part of the ide because it lets the developer build things).

From ide.sh you can see the makefile build tools, unit testing implementation, html documentation updates, project status updates and helper svn functions.

The workspace has automatic makefile generation for managing dependencies between source files and linking. See Makefile Build Tool. What I wanted was a hands off IDE that minimized configuration files and largely works from the source.

The workspace has a unit testing framework. Over time the workspace will develop using this technology.

There is clearly a need to move away from manual to automatic testing where possible. This will give confidence in the workspace to drive more aggressive software goals. More time on software development and less time on tracking and re-fixing bugs. So even if I do not know what is going on, the software will.

The key to getting better software is through transparency. CI Report provides a measure as to what is working. It still requires knowledge to know if the module is important or how relevant the message or module is.