|
|
|
true to my socialist upbringing - "You made the suggestion, you realize it" - let's get things rolling. I picked the code snippet library both out of curiosity, and as a project with early results yet potential to grow.
Abstract:Application to manage a collection of code snippets, working standalone, from a centralized server, or peer-to-peer.
Note: These are my ideas, and assumptions. Correct me if I'm wrong, and feel free to discuss.
First Step - Standalone Client
The Standalone Client enables a single coder to store and reuse small functions, classes, and "unstructured" code sequences of his favorite languages. A desktop application that interfaces the development environment via the clipboard, stores data language-neutral, with extensible meta data, and allows basic organization.
A good paradigm for storing a snippet seem to be files, and using folder as structural criteria. This allows users to "reuse" their organization behavior for loosely coupled data.
Storing each snippet in a physical file has the advantage that cleanup, moving around, renaming, and basic searching comes "for free", again according to the user's choice.
Scalability, might require other storage mechanisms as well.
Benefits: Early "ROI" - we have something "to deliver". Plus, coders can already build their snippet libraries for later sharing.
Networking - Central Server
This will enable closed workgroups to build a common database, and to exchange snippets. A simple Intranet-version could be dereived from the stand-alone version by connecting to a shared folder, or allowing the inclusion fo a shared folder. A web application would allow sharing the data over the internet. Ideally, the standalone application can connect to any folder, shared folder, or URL to access (or at least retrieve) a snippet library.
The Web Application would allwo widest availability, while the standalone application would be targeted to a common interface with location transparency*.
Networking - Peer to Peer
For loosely coupled, server-free application, the client could "piggy-back" Instant Messengers and other P2P software. The technical possibilities to interface common clients need to be evaluated.
general P2P benefits - zero administration setups, running cost is shared between the participants, loosely organized. Plus, it opens up "connections" between the server-based libraries.
Scalability
To make the snippet library feasible for a site of the size of CP (the "ultimate goal", in the following called "big server"), various issues must be solved:
a) defining interfaces and "reuse" between stabdalone and "big server" application. "Read-only" access to the big server is a "certainly possible minimum"
b) Advanced Description: "A snippet belongs to one cat" isn't enough for a library of this size. While a non-repeating strict hierarchy is still desirable, advanced grouping mechanisms (like m:n snippet-category mapping, or keywords) is required.
c) Data Storage: with respect to storage size, maintenance and accessibility, snippet files might be bad.
d) Indexing: advanced search is necessary, without bloating the necessary meta information. Storign the index in a database is of essence for acceptable performance.
e) Quality: Such a large databasse surely clutters up with... less recommended code. Voting (like on CP, perferring main contributors) would be nice, but requires
f) User Management - this should ultimately be able to integrate with "external" user managements, like the one on CP.
g) ???
other topics
a) Integration with Development environments
b) Language-specific Code Representation ("beautifier")
c) Keyword replacement (e.g. snippet "reverse a 'TYPE *' vector in place" would allow me to specify type, and vector name)
d) Extract/Embed meta information from/in language-specific comments
e) selectable "comment header templates" for functions and classes
f) ???
Whew. That's it. For now.
*) shouldn't that be "location opacity"?
"Der Geist des Kriegers ist erwacht / Ich hab die Macht" StS
sighist | Agile Programming | doxygen
|
|
|
|
|
Did you get my email today about the code snippet library and my secret plan?
Jason Henderson My articles
"The best argument against democracy is a five-minute conversation with the average voter." - Winston Churchill
|
|
|
|
|
Yes - Paul is basically interested, and roughly agrees with the proposal. We just wanted to "sync" some basic ideas in the next days before we contact you again. Fnord.
"Der Geist des Kriegers ist erwacht / Ich hab die Macht" StS
sighist | Agile Programming | doxygen
|
|
|
|
|
You will be my "Second Foundation." If you've ever read Isaac Asimov's Foundation trilogy, then you may understand what I mean.
Jason Henderson My articles
"The best argument against democracy is a five-minute conversation with the average voter." - Winston Churchill
|
|
|
|
|
You are going to lock yourself up in a secret vault and at key moments in psychohistory reveal yourself with wise words in holographic form?
Wow. I thought we were just making a snippet library
p.s. Giving all my thoughts to Peterchen now.
Paul Watson Bluegrass Cape Town, South Africa
Chris Losinger wrote:
i hate needles so much i can't even imagine allowing one near The Little Programmer
|
|
|
|
|
Paul Watson wrote:
You are going to lock yourself up in a secret vault and at key moments in psychohistory reveal yourself with wise words in holographic form?
Actually, I'll be dead, but the rest of it is right on. Just call me Hari Seldon.
I'm glad someone else has read these books, but where is this Second Foundation I speak of? right under your nose
I love Asimov so much I'll name a child after him. Asimov Henderson.
Paul Watson wrote:
p.s. Giving all my thoughts to Peterchen now.
good man
Jason Henderson My articles
"The best argument against democracy is a five-minute conversation with the average voter." - Winston Churchill
|
|
|
|
|
Suggestions about the Code Snippet library :
- the infrastructure is already here, it's VS.NET.
- there's an attempt for a code snippet library as a standalone app. Look here[^], API-guide (2.2MB) has a .NET tab with in-context samples. Categorization using the tree is fine and fast to browse. Me like it. :-!
- peer-to-peer ? May be you are going a bit too far here. Centralized with an update every month or so is already more than enough. Anyone interested in seamless updates could use the MS BITS download library (used in Windows update).
Last but not least, an issue : you are not likely to make business with this. That's unfortunately IMHO the kind of stuff which are hard to sell by themselves.
|
|
|
|
|
Stephane:
Thanks for your feedback.
I wrote this mainly as input for CodeProject Projects. basically, Jason, Paul and I are still fiddling around how to continue with it. Until then I appeciate discussions, but want to keep the ball low.
So there's no "make money" idea in it. Trust me, the things I consider marketable I wouldn't analyze that publicly.
Technically, it's just a blog of ideas. Paul agrees with the basic challenge: creating a infrastructure that handles both one-dev standalone and 100k users in a server environment. P2P is just another means of sharing. It might be valuable as server-free exchange for standalone users, and as a "tunnel" between server-based nets.
I'll look into API guide - although it seems to be made for something else.
"Der Geist des Kriegers ist erwacht / Ich hab die Macht" StS
sighist | Agile Programming | doxygen
|
|
|
|
|
Ok IMO there are two tracks to this project.
One is to rehash all the existing snippet library ideas and produce a good but rather unoriginal system. I will get bored on that track and be lazy, the result will be nice and useful but... well we are doing this in our spare time and I want a bit more than just "nice" and "useful" for my spare time
Two is more ambitious, harder to do but ultimately more fulfilling. Two however will cover the above quite easily.
Let me explain.
I see three usage scenarios which are key in understanding what it is we are to produce.
- Personal/Standalone coder. This is Christian Graus. He does not want P2P, he does not want other peoples code, he does not want sharing and rating and community features. He does not want to know about the XML backbone or setting up a code-server or fannying about with webservices. He does not want to even have to login to the application to use it. He wants to be able to store his often used pieces of code and to be able to drag them into his applications with the least amount of fuss possible. For him a standalone client or a VS/.NET Add-In are perfect. No admin consoles for the code-server, no registration and such. Just right-click-store-code, right-click-insert code. The system should let him store just a piece of code without even a title required as well as let him title, categorise and keyword code to make searching easy.
- CodeTeam This is a bunch of guys in a company who want to share code amongst each other over a LAN. The company may say "Here is the preferred code for sorting an array in JavaScript" and it will be available to all. The "code-tree" will be editable by all on the network, code can be added and removed, used and abused etc. This sytem will have simple community features. No ratings, blocking and such. Also each client can have their own personal code-tree independant of the Company code-tree. Also a company may want to setup a template for the data-structure of code snippets to ensure items on the Company code-tree are of a certain quality (title, description, author, usage etc.) This scenario though does not include the web-facing component as it is meant to be kept all in house.
- CodeCommunity This is CP on steriods This is the more ambitious idea of mine. Basically someone will setup a community server and then multiple clients can connect to the server and start sharing code. Each client can of course have their own personal code-tree on their machine. The Community code-tree though will be moderated. Someone submits a new item then it goes into the Un-edited reader contributions section An editor using the client app would then review the snippet and either leave it un-edited (and not officially part of the CCT) or move it into an official Category/Folder. The author of the snippet can edit their item, but then it is reviewed before the edit goes "live". etc. etc. So CodeCommunity is like a internet application version of CP. A bit like Artifact in that way, but without the waffley bits, confusing setup and odd way of doing things. Also a client can connect to multiple CodeCommunity servers as well as to a Company code-tree and have their own personal code-tree. I was thinking a namespace/domain type system would work for that.
Ok so those three scenarios tell me that we need a Client app (standalone and VS.NET Add-In), a Storage service and a Community interface. The Community bit can be built later as really what it is in my mind is simply a web-interface (web-services I assume) to the Storage service. The Storage service will be the key naturally.
Don't shudder when I say I think XML will be a good mechanism for storing the snippets. It is overhyped but it is pretty damned useful and it will make sending snippets over the wires easier, especially through web-services.
Not only that but, and here is another grand idea, XML is, no sh*t, extensible. Code snippets rarely follow a rigid format. Some will have all the fields under the sun filled out, others will just be a code block and thats it. I get frustrated with snippet libraries that ask me for "target platform" when it comes to a piece of HTML, what the heck am I supposed to fill in there? It should not even ask me that. So we can have XML templates. One for C++/C#/VB/Fortran code, another for CSS, another for HTML etc. When someone creates a new snippet it either asks them which template or preferably it knows which template to use based on the category/folder they are creating in or from inspecting the code in the clipboard.
The display would then inspect the snippet, see that it is a HTML templated snippet and display accordingly. We can even offer interfaces which allow people to perform certain actions on specific snippet types. e.g. If HTML then run macro XYZ when item is selected.
I am very much up for a flexible system. One that does not make C++ coders happy but makes HTML coders curse the day it was born.
Also another key of using XML is with the CodeCommunity aspect; It makes it dead easy for CodeProject to merge in snippets from CodeGuru (hypothetically speaking of course, we don't need their steeennkiiing code) or for the snippets to be re-published to an entirely different system. Maybe someone wants to create a client which runs on WinCE, they are free and able to easily do so because the code-tree is exposed by a common web-service interface which streams out XML which they can then XSL or de-serialise or whatever they want to their WinCE client.
It would blow my mind if Chris made all the articles on Code Project available like that. That would be a huge step up IMO. (Of course ad-revenue generation will have to be carefully though through. But when you syndicate your content you can charge for it without ads. Who knows, but I like the idea and the devilish details can sod off till later.)
Ok so that is my idea. The Client, the Storage and the Community interface. A person can choose just to install the Client and a personal Storage and never share with anyone. Or they can download the Storage service, put it on a company server and then have co-workers in the company download the Clients and share in-house. Or Bob can download the Storage and Community interface, setup a server and have a bunch of users with Clients connect and share.
Notes/Ideas:
- Snippet items must definitley be stored as seperate physical files. This may be bad for performance but it will ensure Christian Graus can say "Sod it, I hate this app" then go into the store folder, copy all his code out as files and then kill the app. No proprietary single-file storage mechanism, no "exporting" to get at your code etc. Search performance can easily be managed by managing a search index file where with each edit, delete or update the index is updated. It also makes it easy to email files to co-workers or friends who do not have the app. The system must not lock people into using it for their code, it needs to be open like that.
- Storage of binary files (maybe a screenshot of the code in action or a compiled assembly DLL)
- Syntax colouring
- Do we need versioning? I like the idea but it might prove to be more complex than benefitial
- Multi-categorisation: Most definitley snippets should be able to live in different categories/folders and right from the start. Retro-fitting a one-to-many system to a many-to-many system is never fun
- Online/offline handling must be seamless. No crashing if a community server goes down, cached items still available etc.
- Bookmarking of items and "Download to Personal Code-Tree" functionality
- For the CodeCommunity and CodeTeam systems a robust security model is needed so that we can assign Editors, Administrators etc.
- Put watchers on items and be notified when they change
- I am not too keen on the P2P idea because it will result in a free-for-all fight in the code-tree structure. I don't mind using P2P for discovery and load distribution. Clients can directly connect to each other if needed. It might be overkill having P2P though.
- Super Simple Installation Mode: This is for Christian Graus. When he double clicks that Setup.exe it must only ask him where to put the files and thats it. No "Please rovide a CodeCommunity username and password" or "Would you like to share?" etc. I can see CG cancelling a setup if it bothers him with irrelevant questions. Hard core okes must not be bothered. I want their respect for this system, if we can do that then we have done an amazing thing
I must put together a Visio file of how I see the architecture working. Client, Storage and Community/Web-interface.
So there you go. I have plenty more thoughts on the matter but that is the basic idea I have.
Paul Watson Bluegrass Cape Town, South Africa
Chris Losinger wrote:
i hate needles so much i can't even imagine allowing one near The Little Programmer
|
|
|
|
|
Fantastic ideas Paul.
CodeCommunity sounds like a big undertaking, but the other two are very doable in the short term. Don't get me wrong, CodeCo is a great idea but I think it could wait. Design around the idea though, so it will be easy to implement. But, if you and peterchen think it can be done now, then all the better, and "Go for it!"
Paul Watson wrote:
Don't shudder when I say I think XML will be a good mechanism for storing the snippets. It is overhyped but it is pretty damned useful and it will make sending snippets over the wires easier, especially through web-services.
We all know that XML is just text, but its a standard and there are a lot of powerful things that can and are being done with it. I have no problem with it being used.
Jason Henderson latest CPP news
"If you are going through hell, keep going." - Winston Churchill
|
|
|
|
|
CodeCommunity sounds like a big undertaking, but the other two are very doable in the short term.
Exactly right. The main thing is the central Storage, then next is the Client. That caters for everything but the more ambitious and open CodeCo idea.
I see CodeCo as being an add-on to the Storage layer. All it really is is a layer of web-services to interface with the Storage and a few extra bells and whistles to manage the herd of buttered kittens that a community of coders can be.
So certainly the Storage and Client are doable and will have good results relatively quickly. then when we have the Storage rock solid the CodeCo can be started.
Paul Watson Bluegrass Cape Town, South Africa
Chris Losinger wrote:
i hate needles so much i can't even imagine allowing one near The Little Programmer
|
|
|
|
|
Paul Watson wrote:
Snippet items must definitley be stored as seperate physical files. This may be bad for performance but it will ensure Christian Graus can say "Sod it, I hate this app" then go into the store folder, copy all his code out as files and then kill the app. No proprietary single-file storage mechanism, no "exporting" to get at your code etc. Search performance can easily be managed by managing a search index file where with each edit, delete or update the index is updated. It also makes it easy to email files to co-workers or friends who do not have the app. The system must not lock people into using it for their code, it needs to be open like that.
Really? So we'd have a few hundred files to sift through if we didn't want the app? What's the big deal with exporting to separate files in this scenario?
How would it be easy to find a file (out of hundreds) to email? I think using windows explorer is a pain in the rear, especially when we would have an interface for the user to send a snippet through email in the app.
I don't like the idea of a real database like SQL Server, but a flat file with indexing sounds fine. The app could easily search it, export from it, and if its simple enough, the user may be able to open it in wordpad and find the code he needs.
Paul Watson wrote:
Storage of binary files (maybe a screenshot of the code in action or a compiled assembly DLL)
You realize what kind of crap people would be sending around in CodeCommunity? Pr0n, virii, mp3s, star trek episodes, etc. We'd be making the next Kazaa. Not to mention, its not code and this is a code snippet library. I think binaries should be left out.
Paul Watson wrote:
Syntax colouring
This could probably be built in the app without saving it in the file(s) depending on the language and user settings. Good idea.
Paul Watson wrote:
Do we need versioning?
Hmmm. Would the app do this automatically, or would the user just say this is version 2.0 if they choose to?
Paul Watson wrote:
For the CodeCommunity and CodeTeam systems a robust security model is needed so that we can assign Editors, Administrators etc.
Why not have a community rating system that deletes community snippets if they fall below a threshold?
Paul Watson wrote:
I must put together a Visio file of how I see the architecture working.
I don't have Visio. Is there a viewer or can you export to another format?
All very good ideas and well thought out I might add.
Jason Henderson latest CPP news
"If you are going through hell, keep going." - Winston Churchill
|
|
|
|
|
You realize what kind of crap people would be sending around in CodeCommunity? Pr0n, virii, mp3s, star trek episodes, etc. We'd be making the next Kazaa. Not to mention, its not code and this is a code snippet library. I think binaries should be left out.
Dead right, binary file capabilities for CodeCo woulbe be insane. But for the CodeTeam scenario it is useful. That is in a controlled environment, it is over a LAN so specialist file sharing routines won't be needed. It could even just be a link to a binary file. Hmm, maybe just a "related files" field and that could be to whatever the author chooses, a web page, a text file or an image.
But definitley no binary files in CodeCo. Not until we weed out all the trolls from humanity. i.e. Never.
[Syntax Colouring] ]This could probably be built in the app without saving it in the file(s)
Definitley. And we even have an awesome syntax colourer right here on Code Project, that Brain one. Apparently it is fast and open.
I am all for contacting article authors here on CP who have written code we could use. We should make use of CP
Would the app do this automatically, or would the user just say this is version 2.0 if they choose to?
Automatically I think. But we may be stepping on the toes of the source safe project in which case we should either find a way to integrate or leave it out. We will see.
I don't have Visio. Is there a viewer or can you export to another format?
Don't worry, I won't use any proprietary formats for our documents or designs (that is another thing that should be sorted out for the CP2 projects; What file formats for documentation etc., Word? Not everyone even has Word.) Visio can export to JPEG for now.
Really? So we'd have a few hundred files to sift through if we didn't want the app? What's the big deal with exporting to separate files in this scenario?
Not fully thought through yet. I probably jumped the gun a bit actually in even bringing it up. Like any good project we should first gather requirements and then only start thinking about the actual architecture and technologies. Closer to the time we can argue over this one
Paul Watson Bluegrass Cape Town, South Africa
Chris Losinger wrote:
i hate needles so much i can't even imagine allowing one near The Little Programmer
|
|
|
|
|
More info on the Hari Seldon/Foundation thing (My grand plan)
I don't have an elaborate plan of Galactic salvation though military might or mind control. Sorry.
However, peterchen expressed his concerns about the chosen projects not being useful, but being cool. I am also concerned about them, even though I don't think they will fail, there is a possibility they might. This is where you two come into the picture as my "Second Foundation."
The Foundation was open and known to the galaxy. It was founded as a scientific community to hedge against a midevil time period after the fall of the galactic Empire.
The Second Foundation, was an enigma, a legend. They were the psychohistorians that controlled the fate of the galaxy. They were around to make sure things turned out the way they should.
Our first three projects are open to all of CP and everyone not living under Bob's spaceship has heard about it. I'm trying my best to control things until the projects start then I will only have influence from afar. There is a possiblity that the projects may collapse in chaos and disarray when 20 or 200 people try to help out.
Your project will be somewhat less open. You'll have a project article series but I don't want you to let just anyone on the team, I want you to invite people based on their credentials. I'm sure you can find several high caliber people here, like Christian Grause and Daniel Turini who have expressed an interest in CPP. I'd like you to even ask people who haven't volunteered. If you want to open it up to anyone after you get a core of good people, that's fine.
Once we setup the other projects, I want you to improve on everything we've done. Even though I won't be directly involved, unless you ask me to be, I'd love to stay informed of your progress. So this is your baby, you do what you think is best. Just enjoy yourselves and write a great program that can be used by everyone on CP.
Jason Henderson latest CPP news
"If you are going through hell, keep going." - Winston Churchill
|
|
|
|
|
What a terific idea. No wonder Chris voted you Most Likely To Herd Cats Successfully.
But we must do this Second Foundation idea in a careful way. Not keen on being seen as elite or not following the "rules" of the other projects.
Just enjoy yourselves and write a great program that can be used by everyone on CP.
Yup, the moment someone starts getting anal about all of this I, and I bet many others, will shove off. This is our spare time, we want to enjoy it, learn from it and come out with something useful.
When peterchen gets back he and I can dig into the idea and set it up to move forward.
Paul Watson Bluegrass Cape Town, South Africa
Chris Losinger wrote:
i hate needles so much i can't even imagine allowing one near The Little Programmer
|
|
|
|
|
Paul Watson wrote:
No wonder Chris voted you Most Likely To Herd Cats Successfully.
I had no idea this honor had been bestowed upon me. When do I get my medal?
Paul Watson wrote:
But we must do this Second Foundation idea in a careful way. Not keen on being seen as elite or not following the "rules" of the other projects.
You should follow the rules, but modify them if you feel you must. If you need my signature on a change, then I'll be glad to lend my miniscule amount of credibility to the change. In the least, get a good core team that thinks this is a great idea then open it up to the masses. Most people understand that Platinum members and the "elite" CPians deserve the recognition they get.
Paul Watson wrote:
Yup, the moment someone starts getting anal about all of this I, and I bet many others, will shove off. This is our spare time, we want to enjoy it, learn from it and come out with something useful.
Don't let them get anal. Its your team, kick their butts off.
Jason Henderson latest CPP news
"If you are going through hell, keep going." - Winston Churchill
|
|
|
|
|
OK Paul, let's take number two
3 use cases:
agree.
I hope to count on your Experience for No. 3 - Code Community My webdev experience tops at a 6-person-intranet...
Storage:
Yes, I thought of XML because it's extensible and text. Yet, extracting the snippet from the XML file won't be that easy... (and we have to escape the snippet text)
I like the idea of using a folder structure for the storage, so CG can move around snippets by himself, folders can be used for "access control" (e.g. allow person A to access Folders X and Y...). Small teams could set up a shared snippet library on a file server etc. and implement security restrictions by themselves if required.
Problem: "CodeCommunity" does indeed need an index DB, but this needs to be re-index everytime CG moves around some snippets by hand.
Attribute Templates:
Definitely a good idea.
I already considered a "free" list of attributes for each snippet, just a map string name -> string value. There can be predefined attributes like "Language" (which affects the syntax colorer choosen) etc.
The template can store a set of attributes, with both default values, and "possible" values. e.g. Template "C++ snippet":
Language: C++
Target Platform : [empty] { Win32 | MFC | ANSI C++ | ... }
By just selecting "C++ snippet" I get the correct markup, and relevant fields, and can quickly pick "Win32" as platform.
(Of course, the setup provides default templates, and the user can make new ones)
Using only strings as attributes:
Might seems like an arbitrary restriction. However, the only relevant non-string attribute I can think of (i.e. that needs custom sorting) is "Date", but this can be stored as YYYY-MM-DD string, so it sorts correctly. Allowing arbitrary types as attributes seems to add quite some complexity without much benefit.
Your opinion?
Many-to-Many:
We definitely need a many-to-many indexing, but my experience is that people work better with "strict" hierarchies as long as complexity allows - and even beyond that. So I would favor a "Hierarchical" access (correlating with the storage structure) and a "M:N" - access (probably based on keywords and/or attributes)
Language Dependance
A simple version can well live without any knowledge of the language the snippet is in.
Language dependency only comes in with syntax coloring, search, etc.
Binaries:
Hot topic, I agree...
If we take them in, CodeCommunity and CodeTeam should both allow to
- limit adding binaries to individual users/directories
- allow setting a size limit
- allow all users to filter out binaries
Storage - as seen by user
CristianGraus and CodeTeam probaly get along well with a "local store" (i.e. accessible via the file system), and the possibility of importing a "remote" folder (creating a local copy) from an e-mail, a web server, or a P2P connection
(This is the only case where I see P2P could be handy - sharing over the internet without setting up a server. However, it makes sense only when we can piggyback a well-known IM client)
The Server.. needs to be different.
First, it should be applicable as "Web only", i.e. you can search snippets, copy them to the clipboard, etc.
Second, the client should be able to connect to it, so people can use the dedicated client to browse the library. However, we must avoid people DL'ing the whole snippet library and stalling the connection. (btw. A "proactive" solution would be offering a complete zipp'ed archive)
Well... here I need your ideas.
btw. could you contact me by IM again (tonite, or any evening)? Didn't store your ID... Would be good if we could discuss some "administrative" stuff, and basic design (like what langs to use and how to go on) P2P.
"Der Geist des Kriegers ist erwacht / Ich hab die Macht" StS
sighist | Agile Programming | doxygen
|
|
|
|
|
Great ideas guys. Sounds a lot like: http://artifactsoftware.com/[^]. I didn't think Artifact Desktop was that great though. Slow loading, crashed a lot (for me anyway), and a difficult UI. What you have planned sounds a lot better in so many ways.
Steve
McLenithan
Is Bert Evil? | Homer: "Hello, operator, gimme the number for 911!"
|
|
|
|
|
I realize it's been quite a few years since this was posted. I was curious as to how far the project progressed. I'm interested in the CodeTeam version of the project. It sounds like the perfect solution to a need my team has.
If the project was realized, is it available for use? if so, where can I find it?
Thank you
|
|
|
|
|
OK Code Project Project is the craze of the day.
disclaimer: it's cool to come back from 4 days off and see such a thing. Jason, you're doing good! (You must be doing good otherwise you would get quite som flak ) These are just casual observations.
1) Minor: the usual some "self-obsessison": We discuss the Tools before we have the Task. There is no "Until someone objects we use SourceForge". We all like to think about such tools (count me guilty), because they're cool. Tools to manage such a project even pop up as potential project. Mozilla Mistake.
2) MAJOR: The project to end all projects
Potential projects are voted on by "coolness". THE ai, THE ui library, a Project Management System - without a visionaire who has a clear idea what makes it so cool. Heck, one project gets votes for it's (admittedly cool) acronym. Are we fallen for the geek marketing yet?
I miss case studies, use cases, ideas, suggestions, limits, some driving force etc.
The only thing that stuck with me is the ASP.NET control replacement - because it's a limited and (for the moment being) well defined task. The others I remeber are so fuzzy. An AI? What? To discuss with? To play chess? Compose music? Take over the world? A "can be everything" AI?
Count me in, but we should do our homework before.
"Der Geist des Kriegers ist erwacht / Ich hab die Macht" StS
sighist | Agile Programming | doxygen
|
|
|
|
|
I must admit, I jumped on the idea of a massive project because that's the way my mind tends to go.
I quickly jumped off again, though, once it became apparent just how difficult the startup process was going to be. I think if the project can get past the decision-making stage, and then past the let's-everyone-agree-on-a-design stage, then there is a good chance the project will succeed.
Otherwise...
But I agree, AI? That's a little broad. And something best left to people with large budgets. The control libraries (ASP/MFC) is probably the best bet, with the book as the next, although the book would need someone who seriously knows the publishing industry.
Perhaps a better way of doing it would have been to find someone who is as keen on a project as you are, and in a small group hash out the details. Decide what you're going to do and how. Document it. Then come to the 400,000 members and say, "We're going to do this. Do you want to help?"
J
"You can get anything you want at Alice's Restaurant."
|
|
|
|
|
Jamie Hale wrote:
although the book would need someone who seriously knows the publishing industry.
Isn't it great that we have at the very least two well known authors (Tom Archer and Christopher Duncan) on board CP? What with Nish rising up the publishing ranks and I am sure a few other authors amongst the CPian-base we have a good amount of knowledge about the realities of publishing a book.
Jamie Hale wrote:
Perhaps a better way of doing it would have been to find someone who is as keen on a project as you are, and in a small group hash out the details. Decide what you're going to do and how. Document it. Then come to the 400,000 members and say, "We're going to do this. Do you want to help?"
The ownership would have been far less then. There would be a cabal of top men and then the rest are just grunts pushing code rather than believing in what they are doing.
Having an open policy is best IMO.
Paul Watson Bluegrass Cape Town, South Africa
Chris Losinger wrote:
i hate needles so much i can't even imagine allowing one near The Little Programmer
|
|
|
|
|
Paul Watson wrote:
The ownership would have been far less then. There would be a cabal of top men and then the rest are just grunts pushing code rather than believing in what they are doing.
Having an open policy is best IMO.
Granted. But just to get it off the ground, I think you need this kind of small focused group. If the active CPP is going to have 20 developers trying to get their say in on the design, the project will a) go nowhere or b) have such a lack of focus that it won't end up being very useful.
Just my 2 cents.
J
"You can get anything you want at Alice's Restaurant."
|
|
|
|
|