User:FuzzicalLogic

Profile and Contact Information

 * Name: Donald Atkinson
 * Age: 30
 * Profession: Software Developer
 * Location: Albuquerque, NM
 * E-Mail: fuzzicallogic[at]gmail[dot]com

This is my standard messaging name and I may be reached at GMail, MSN, AOL/AIM, Yahoo and various other forums and messaging services with this name. As the use of names cannot be regulated, the above are guaranteed to be owned and used by myself, while I cannot do the same with others. I am open for professional and nonprofessional discussion. Professional requests and discussions may be responded to from by business mail account (not listed here).

Interests
Varying widely, my hobbies and interests range from Music Collection to Video Game Development. Among my strongest interests are:
 * Role-playing (Table-Top)
 * Software Development
 * Information Technologies
 * Music History and Theory
 * Video and Computer Gaming
 * Philosophy and Intellectualism (anti-elitist)
 * Business and Market Trends
 * Artistic Development and Conceptualization

Software and Expertise
My career began in 1996 as a database software developer. My first exposure to professional programming was with MS Access 95 and quickly expanded to VB 6.0, MS VC++ 6.0 and beyond. I now have a comprehensive practical knowledge of many languages and seek to design and implement software that is community and business oriented. Usability is a prime focus of all of my projects, and hence, typically defines which projects I will become an active part of. I am currently working to patent three new technologies focused on recombinant compression.

Some additional projects include:
 * ELI (Extensible Language Interface) - A language reference for Windows-based computers as a service. This tool uses concepts from the compression technology mentioned above.
 * nSOL - A proprietary programming language focused on advanced object orientation, alternative number systems, and educational programming.
 * STEP - A Version Management\Patching System for publishing and distributing software updates and application builds.

My MediaWiki Experience
I started using MediaWiki several months ago as a CMS for my intranet development site. I have downloaded and used a variety of extensions for my wikis. I immediately saw the applications of using it for customer and technical support and have been adjusting my own Wikis toward that end. Learning MediaWiki was an obsessive task for me, but has been very worthwhile. Until recently, I was an anonymous user but have decided I would like to begin posting my own extensions as they are completed. I find them to be incredibly useful for myself, and hope that they are for others as well.

Currently Used Extensions
This list is changing regularly as I complete my own extensions for my own customized needs.
 * Extension:CategoryTree
 * Extension:CrossNamespaceLinks
 * Extension:DeleteBatch
 * Extension:DisableSpecialPages
 * Extension:ExtIdx (Extended Index)
 * Extension:geshi
 * Extension:Glossary
 * Extension:Google Analytics Integration
 * Extension:HeaderFooter
 * Extension:HNP
 * Extension:Icon
 * Extension:LightboxThumbs
 * Extension:LiquidThreads
 * Extension:LoopFunctions
 * Extension:MetaTags
 * Extension:NewArticleTemplates
 * Extension:ParserFunctions
 * Extension:SidebarEx
 * Extension:StubManager
 * Extension:Tooltip
 * Extension:Variables

Extensions in Progress
These are extensions that I am currently working on for my own Wikis but believe them to be useful for others. My philosophy toward extension development is to develop with as few dependencies as possible, while allowing for interoperability. This is particular true for customization and configuration, as long as the customization does not impede the actual functionality.

Extension Extenders
These extensions extend the interface, installation and customization of MediaWiki Extensions. They are provided neither to replace functionality nor to force adherence to any standard. They are, instead, developed so that extensions that choose to utilize them may do so for ease of use by other MediaWiki users. Any extension that wishes to do so should be developed without dependency upon these extensions and should be fully functional in their own right.
 * Extension Consolidation Configuration Options (ECCO)
 * Concept: This extension is a SpecialPage allowing for user-friendly customization of configurable extensions (including itself). Extensions should self-register (upon first use) into a quick-loaded non-wikiparsed registry. Once registered, the ECCO interface will allow admins to change option values for configuring these extensions. Extensions that wish to register with ECCO must be functionally independent from ECCO as one cannot guarantee its presence on a Wiki.


 * Status: Currently, the SpecialPage is seemingly fully functional, but as of yet, I have no fully self-registering extensions. Once at least one of my extensions can work with (and without) ECCO and can provide a proof of concept, I will upload ECCO. This is approximately one month away.


 * Extension Help Documents
 * Concept: Provides a standardized tool for installing documentation with an extension. On first run, the plugin will add its documentation (not talk) to the appropriate namespace for easy viewing by the user. The Parent Category and Namespace are configurable and options for protection are included for those who have a need to keep functionality secret for security.


 * Status: Fully functional. Integration with ECCO desired before upload.

Security Extensions
These extensions are used as supplemental security measures. They are not meant to replace current implemented security measures. They instead work by obfuscating or protecting specific types of information including links, addresses, and code. These additional security measures typically require more processing and memory than the standard operation of the Wiki and may increase page load times and/or submission times. Use at your own risk.
 * Improved Invisibility
 * Concept: This extension removes links to pages/actions that a User does not have access to. Protected links are removed before dispensing information to the client. The approach is straightforward for the action-bar and User-pages. Most of the SpecialPages are hidden properly with little configuration. The ultimate goal is to have even articles that reference private pages render as text instead of links. This would require superceding parser functionality.


 * Status: To date, the following work correctly: Action Bar, Personal Bar, Sidebar, SpecialPages. Parsing within specific articles is too time intensive for my tastes, but works adequately enough for proof of concept.

WikiStyles (WS) Extensions
These extensions are a "suite" of extensions that allow display and functionality customizable through CSS articles rather than CSS files themselves. The object here is to allow users and admins to configure the look of pages and components without having to adjust code or directory structure.
 * BreadcrumbsWS
 * Concept: Inspired by CategoryBreadcrumbs, this extension puts a div of Breadcrumbs onto the page. By setting Wiki Options, a heading, the delimeter, maximum length and number of branches (for multicategorized articles) may be customized for the specific Wiki. These are further stylized by a CSS Article accessible through the Special Pages interface.
 * Status: Fully functional independently. Will be submitted when full integration with ECCO is complete.


 * NamespacesWS
 * Concept: This extension allows for the customized look of articles located within a given namespace. Articles would be located at Namespace:/CSS and supercede CommonCSS, but can be configured to be overridden by User CSS pages.
 * Status: This is currently experimental and only partially functional. Would like some configuration options regarding the location of CSS articles before this is submitted.

Administration Extensions
These extensions replace or extend the current functionality of some SpecialPages to allow for full configuration within the Wiki for Sysops and Admins. These will include a host of tools including Namespace management and User Management through SpecialPages. The primary motivation of this was to automate to running of certain maintenance scripts when specific actions were taken. This has, since, expanded into a full administrative suite. With regard to security, these will, hopefully be able to meet the needs of most Wikis, but will require extensive testing and may be in experimental or beta status for awhile before an acceptable release is submitted.
 * Namespace Adminstrator
 * Concept: This extension allows for the configuration of namespaces via a SpecialPage. Because this functionality is not new, certain functions such as the renaming and moving of articles within a namespace should be automated. This page would not allow the manipulation of articles but would allow for the basic configuration of Namespaces as generally provide by LocalSettings.php.
 * Status: This is currently experimental and only partially functional. It is not adequately protected and, as such, is not suitable for upload.

Other Extensions

 * MobileWiki
 * Concept: To allow practical access from a handheld device. When a page request is made, the extension will check the UserAgent for a variety of strings and return specific parts of a page according to the TOC and article structure. Because UserAgents are not a catch-all for any request, a customizable CSS file for media-types will also be supplemented for CSS capable handhelds. This will limit the CSS downloads required for the page to be rendered on the handheld and, hence, limitting the bytes.
 * Status: In design. Development to begin as time allows.

Submitted Extensions
Sadly, to date, none of these extensions have been submitted due to my desire to reach the landmarks set aside above. While I am happy to submit to a direct request for testing and potential collaboration, these extensions will not be submitted until these landmarks are reached.

Extension Requests
You may request extensions directly by contacting me at the above email address. This is not recommended for a number of reasons:
 * The MediaWiki community of developers is very capable and friendly, particularly at collaborative works and to request from a single member often undermines the community and the strength that comes with it.
 * I prefer to work with Extensions and not Hacks with the MW Core. As such, an extensible solution may take a little longer than a hack. This is important to me and does lengthen development time.
 * Extension requests are typically made for specific needs and, hence, payment may be required. If this is a concern, please place your request on Project:Extension_requests. I do look at these and am interested in helping members in the community in whatever way that I can. I simply have priorities and cannot guarantee, without payment, that a request can be fulfilled.
 * Any work submitted here is provided free of charge and unless specifically requested or denied any such request will lead to the work and code to be submitted at this place.
 * There may be an extension that performs the work you are asking for. I assume, when accepting formal requests, that you have done the research required and have determined that current extensions do not meet your needs.

If, even despite the above reasons, it is important to appeal to me directly, feel free to do so. Please make sure that your idea for an extension is fully thought out and that you are available for testing. I prefer a quick release schedule, but do need adequate time for a structured design process.