Last updated 2022-05-12
I have many various projects, sometimes too numerous to keep track of. I have two main areas of projects, my personal projects and projects I work on at Tagdot. My personal projects are generally put under the umbrella project called not [your] everyday Applications or neApps for short. Below are a list of some of my projects and PAQs about them.

neThing/in deep thought

neThing is also a kind of umbrella project that at the moment has two implementations. neThing as a singular project is meant to provide the best way of displaying dynamic documents depending on the users requirements.

The first implementation of this is the code behind in deep thought and has the official title IDT.neThing. It is not meant to be blogging software since it should be adaptable for many things dealing with simple dynamic display of documents small group or single person, however most people would call it blogging software. The main features of this project is creating posts in the wiki style (wiki codes with my own set of extensions, history, talk pages), organization of documents through the use of a simple but robust tag system, and dynamic function calls that can grab data from other areas of neThing.

This implementation will also have API hooks for allowing posts to gather data from various tools such as neTodo, neBoards, Sparce, and neCode through the use of dynamic function calls.


The second implementation of this is a much larger project to display complex dynamic documents and templates for a large organization with a complex hierarchy. Part of that display is organizing documents within each org unit (or a single level of multiple org unit) with or without timelines for managing progression of each document within an org unit.

Document layouts need to be templatable (an org unit is given a document to fill out) or fully dynamic (an org unit fully decides the layout of a document) or some combination of both (an org unit can tailor a templated document to their specific needs and/or add completely new parts to the document). Much of this is done through the use of Components which can be added at any point in the document. An example of this is the Text Component which can be either display (the layout administrator adds text that is not editable by the org unit) or input (the org unit must themselves edits the text to be displayed).

Another component example is the Template Component which is a named collection of components (other than another template) that a document layout may use either in singular form or one that a document can have multiple of at any given time.

The Text Component may use a wiki parser for its display. History is also maintained for each component (when possible or necessary or in different forms depending on the situation).

Discussion of the document can be handled inline through the use of the Comment Component or in a Talk page which is present for every document.

Documents may have shared areas that are the same between multiple other org units of the same parent org unit or the same level. Templates are often used to handle this, but individual components can be used in this manner which some slightly less capabilities.

Documents may pull parts of other documents into their document, this is done mostly through templates as well, but individual components can be named and this pulled as well.

The tagging system is at once much more extensive and dynamic as well as rigid in its possible implementation. Documents do not use tags for organization since the institutions departmental hierarchy largely takes over that function, however components do. Sub-root org units (the org unit directly under the Application level, often called Institution) can each have their own set of Classifiers (hierarchical tags) that may be applied to any component defined as classifiable in the layout. This tagging system can have multiple uses such as for Strategic Planning and activity reports based on criteria of topic.

Simple documents may comprise nothing more than a bunch of Text Components (both view and input). More complex documents may comprise templates of text, multiple spawned templates, tables of data pulled from inside or outside databases (or simply an inline table created within the document itself) and graphs for said table, uploads, etc.

This has been implemented a couple times in different iterations. PRISM, Pearl, and Faculty Activity Documents are some of these implementations.

As mentioned both implementations can share features. One such a feature is the function call system that uses {} brackets for example {posts.projects.neThing.Text} could be a function call that would display this whole section of text in another post. More than that there are special commands explicitly implemented to add dynamic text to a post or document such as {UpdateDT} or {orgUnit.Name}.


What is neBoards?

neBoards is now an umbrella name for a project comprising 2 parts.
  1. neBB - a simple bulletin board. So simple in fact that it is what I call a drop thread BB.
  2. neForums - Formerly named neBoards. A highly customizable and easy to use message board.


What is a drop thread BB?
  • A drop thread BB is a bulletin board that can be deployed using a very simple database and script internally OR externally
  • The BB script automatically creates a BB based on the URL that called it
  • Any page that calls the script (internally or externally) must be supplied the relevant threads and its posts if it is on the whitelist/unless it is on the blacklist
  • If the URL (anything before # or ?) is not already known a new BB is created.
  • The host of the script is responsible for images and posts on all BBs



What is neForums?
  • As mentioned before. A highly customizable and easy to use message bard.
  • It can be used as simply as a drop thread BB can or as a huge message board filled with many forums, topics, threads, and posts.


Why was neBoards changed to neForums?

neBoards is a partial acronym for 'not [your] everyday [message] boards'. In that vein as i've come up with new ideas i've always suited neBoards to them. For a while I have been thinking about drop threads and been trying to think of how they would fit within the neBoards system.

So instead of trying to kludge things together I decided to:

  1. Keep the two things apart, except where it makes sense (the most simple neForum is essentially a drop thread BB)
  2. Rename neBoards to neForums
  3. Umbrella the two together into the neBoards project

What does that do to the roadmap?

Completely destroys it. I became unhappy with the neBoards code at some point. I did not want to completely wash my hands of the code and start over but this fact made me not want to work on it at all. Sometimes I have found taking a bigger leap is easier than taking a smaller leap. By reworking the entire concept altogether I have become both more excited about the project and willing to start from scratch with neForums.



Though for some reason I never properly updated this description when I re-created neTodo in .NET, as reflected by the link on this page pointing to that old version, I have re-re-created neTodo in .NET. That means the primary web project is currently the most up to date version that will be used to create now future Windows neTodo app.


Currently there are two projects I am working on called neTodo. One is a Java app the other is was started a while ago which is written in Cold Fusion. The focus of the java neTodo project is to take the Look and Feel of the CF neTodo project and port it. Eventually the online neTodo and java neTodo will be able to sync together. I also intend to extend the functions of both to include task dependencies, categorization (or labeling), better prioritizing, and add a calender for due dates.



Sparce is my demo for taking various RSS feeds (right now it uses and creates a list of links categorized based on your preferences.



B.O.B. or Bash Oppressing Bytes or neBOB is essentially an alternative Bash or command line prompt for accessing various programs. It is a proof of concept for taking English like commands rather than simple commands that are typical with prompts today. While this is behind what some consider as the step forward with graphical user interfaces it could be a first step to English (or later other language) driven computer operating environments. The next step being an Intelligent program that can understand complex requests for resources in a conversation like basis. This is a future project and not currently in development.


A simple command line calculator. Which will take most math expressions as is and attempt to solve them. Examples of such expressions: "1 + 2 * 3", "9 ^ ( 1 / 3 )", and "x * 9 = 18". Most other functions would be handled through slash commands.


Tag based online listing of things. You can tag any item in the list, view by a set of tags only while keeping the depth intact, and can export or import using xml.


A specialized version of neList specifically meant for creating whitelists and blacklists. From net addresses, companies, emails, to food. Based on the tag and reasons, anyone could add to the list or export for their own purposes.


A code repository searchable by meta data applied to the code and the code itself. Can be as simple as large projects with forks and merges. Can attach tags, dependencies within or without the repository, documentation, or other file resources to the code. Keeps a history of all changes made, allows compares and reverts.

posted by dharh 9:13 PM Feb 23rd, 2006

2024: 1
2023: 4 2 1
2022: 5 3
2011: 5 3 1
2010: 12 9 7 1
2009: 12 11 8 5
2008: 12 5 4 3 2 1
2007: 12 11 10 9 8 7 6 5 4 3 2 1
2006: 12 11 10 9 8 7 6 5 4 3 2 1
2005: 12 10 7 6
2004: 10 9 6 5 4 3 2 1