Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
 Welcome to our latest new user Harvey ! (Registered 2024-11-25) You are not logged in - nap
CSDb User Forums


Forums > CSDb Info > CSDb V2
2005-11-09 12:51
Perff
Administrator

Posts: 1679
CSDb V2

As some of you might have seen, there have been talked a bit about a CSDb V2.
I have also had this idea for some years now, because of some basic flaws in the originally database design of CSDb.
Now is the time to try to do something about it.

But we, the current CSDb staff, don't have the resources to do this, so we need your help!

Here is what we need:
1. Somewhere to host CSDb V2. The current hosting for CSDb is not very good, as some of you might agree on, and it would be very difficult for more people to develop on it, so a new hosting place is needed.
The requirements for such place are not to much. Talking about performance, CSDb can run on any normal computer today with no problem, and a few gig of disk space should be ok. The daily trafic sums up to about 40-50.000 hits and 300-400mb.
Some kind of CVS or similar to make it easy for multiple people to develop on it, is also required. (PS. We got no money! )
2. People that would help. First of all we need some willing developers - PHP & SQL. I don't think we should get too many - 2-3, perhaps 4 (plus myself :) ) We'll figure that out.
Also some design people, to make the site look kewl. :) And finally some people with deep knowledge of the scene so we are sure to get around every corner in the design phase.
3. Time and patience. :)

The plan is then to put togehter a CSDb V2 team (not to big, 6-8 people tops), and figure out exatcly how to make it. Of course we should look at the current CSDb, but I sugest we make everything from scratch.
Most importaint is the design phase. We must try to take all into account when designing it. I think this is the most importaint part of it all.
Then it gets coded, designed etc, and when it is ready for release, we transfer all the data from CSDb to CSDb V2. :)

Even though the CSDb team is the ones who should make it, it dosn't mean that the rest of you have nothing to say. Perhaps we could post our plans somewhere for all of you to comment on.


That is roughly how I see it.
Now lets have a nice little discussion. :)
 
... 91 posts hidden. Click here to view all posts....
 
2022-05-21 10:53
Burglar

Registered: Dec 2004
Posts: 1088
If your only tool is a hammer, every problem looks like a nail.
2022-05-21 15:49
chatGPZ

Registered: Dec 2001
Posts: 11354
Another important thing to consider is: There must be multiple persons who know all the tech and can expand and maintain it. If you are the only one who knows a certain piece of the stack, it is doomed to fail on the long run.
2022-05-21 15:57
instant

Registered: Mar 2020
Posts: 20
I appreciate the feedback. I'm working with the information available to me. If Hedning or others want to chime in that would be great.

Believe it or not I've been doing successful software and hardware development and managing development teams for the past 40yrs. I'm confident in my ability to make stuff happen. ;)

This is fun for me. If others want to help, I'm happy for them to join in.
2022-05-22 08:51
Youth

Registered: Aug 2003
Posts: 43
I have quite some experience in building enterprise software and would, like Groepaz, advice to do a bottom up approach, focusing on the database. Gather information about how the users use CSDB, and how they want to use it. See how the current model fits those use cases or make a redesign.

Then think of a way to disclose that information with an API that is specific enough to support the envisioned use cases, but flexible enough to discover new ones.

Then build a UI on top of that API with a well thought out interaction design. Then paint it a nice color and smooth out the cracks.

This sounds like building a house, but unlike building a house, I would do it in small iterations with a short feedback loop, by having something simple that works and can be tested early on.

At the bottom use proven database technology. An SQL database like Postgres might sound old fashioned, but it's very mature, robust and has an immense user community.

For the rest of the stack, use technology that has some track record, is well maintained and has a big user community. REST/JSON or GraphQL are obvious choices for the API. Decide if you want a single page application or a (regular) multi page application and choose an established frontend technology based on that.

Keep in mind who will be working on this. To keep this project sustainable over time, you need a team of developers, with people swapping in and out. So open source it, with a small team maintaining control over the core design and the process of accepting changes from other developers.

So TLDR; Focus on data and user interaction with the data. Choose a tech stack that is modern enough to not get outdated soon, but mature enough to be stable, well maintained and has a large community to support it. Build a developer-friendly work environment to build and maintain the software over the long run.

N.B. this is a first draft of how I would approach it. Pick, mix or ignore at your own will ;)
2022-05-22 09:43
Mr. SID

Registered: Jan 2003
Posts: 424
Obviously the only way forward is to merge with GameBase64 and switch to a Microsoft Access database…
2022-05-22 14:04
Elder0010

Registered: Apr 2011
Posts: 7
Quote: I have quite some experience in building enterprise software and would, like Groepaz, advice to do a bottom up approach, focusing on the database. Gather information about how the users use CSDB, and how they want to use it. See how the current model fits those use cases or make a redesign.

Then think of a way to disclose that information with an API that is specific enough to support the envisioned use cases, but flexible enough to discover new ones.

Then build a UI on top of that API with a well thought out interaction design. Then paint it a nice color and smooth out the cracks.

This sounds like building a house, but unlike building a house, I would do it in small iterations with a short feedback loop, by having something simple that works and can be tested early on.

At the bottom use proven database technology. An SQL database like Postgres might sound old fashioned, but it's very mature, robust and has an immense user community.

For the rest of the stack, use technology that has some track record, is well maintained and has a big user community. REST/JSON or GraphQL are obvious choices for the API. Decide if you want a single page application or a (regular) multi page application and choose an established frontend technology based on that.

Keep in mind who will be working on this. To keep this project sustainable over time, you need a team of developers, with people swapping in and out. So open source it, with a small team maintaining control over the core design and the process of accepting changes from other developers.

So TLDR; Focus on data and user interaction with the data. Choose a tech stack that is modern enough to not get outdated soon, but mature enough to be stable, well maintained and has a large community to support it. Build a developer-friendly work environment to build and maintain the software over the long run.

N.B. this is a first draft of how I would approach it. Pick, mix or ignore at your own will ;)


I could not agree more.
At the cost of sounding rude, I also suggest to use stable and mantained technologies. Ignore fanciness and go for mature solutions, if you don't want to trash the whole project after 2 years or hire a full time developer to mantain it. Basically any "super cool js thing that does something already existing since 30 years ago in a different way because js is cool and you're old" must be avoided.

Mysql or Postgres can handle *millions* of records, and since the nature of the data here, the only way to go is to use a relational approach (if you don't want to lose your data).

As a matter of personal taste, I suggest also to take a look at django framework. With djangoREST you can easily build up an api.
2022-05-22 15:10
chatGPZ

Registered: Dec 2001
Posts: 11354
youth+++
2022-05-22 16:16
instant

Registered: Mar 2020
Posts: 20
The goal is to not recreate the same thing with the same problems.

It should be as simple and flexible as possible.
It should be easy to maintain.
I don't think the tech that is selected should cater to the least common denominator. Anyone wanting to help should have a desire to learn some new things and be savvy enough to figure it out with the help of some good documentation and well commented code.

I need to do more testing but I think I've got most of the backend tech and database worked out already. It will be flexible enough to extend data easily and handle use case exceptions that may crop up.

A vague idea of the user interface needs to be kept in mind while working on things but that is not important until the data and backend/middleware are functional. My priorities are:

1. Make it work! It has to be accurate first or it is worthless.

2. Optimize! Make it as efficient as possible. This is an ongoing iterative process that will be revisited over and over during the life of the application.

3. Make it pretty! This is where all of the fancy UI stuff is worked out. Also an iterative process. Most important information first. Organize the display of the information and making it pretty. Extend UI functionality as we go where it makes sense.

4. Enhance with extra services. API for external applications / RSS feeds / Webhooks / Integrations

People keep saying I need more in depth scene and user interaction knowledge. I totally agree. I'm working based on the information I have at the moment. Mostly from my own experience with the site, what I have read here in the forums from others, and experience from similar projects over the years.

Who wants to dig in and interview Perff, Hedning, and whoever else to define some requirements and use cases? I'm happy to do that if they will get in contact with me. I have recently reached out to Perff but have not gotten a response. I'll contact Hedning.

Everyone is happy to tell me what I need to do or tell me what they think I'm doing wrong but no one is stepping up to offer to help. This thread has been dead for years. I don't mind taking the lead on this. I'm going to do it with or without anyone's help. I'd prefer that others join me though. It will be more fun.

Contact me and let me know what you are good at and what you want to help with.

PM here or idolpx!ircnet / idolpx!efnet
2022-05-22 19:04
chatGPZ

Registered: Dec 2001
Posts: 11354
Sounds like another one-man show with no future beyond the interest of the one single dev.
2022-05-22 21:05
Youth

Registered: Aug 2003
Posts: 43
Quoting instant

Everyone is happy to tell me what I need to do or tell me what they think I'm doing wrong but no one is stepping up to offer to help.


Sorry about that, I am definitely interested in helping out. PM sent.
Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
Mike
Scorpion
bugjam
Barfly/Extend
mankeli/Extend
t0m3000/hf^boom!^ibx
saimo/RETREAM
REBEL 1/HF
Perplex/Offence
deetsay
Marq/Fit^Lieves!Tuor..
Guests online: 64
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 Mojo  (9.6)
6 The Demo Coder  (9.6)
7 Uncensored  (9.6)
8 Wonderland XIV  (9.6)
9 Comaland 100%  (9.6)
10 What Is The Matrix 2  (9.6)
Top onefile Demos
1 Layers  (9.6)
2 Party Elk 2  (9.6)
3 Cubic Dream  (9.6)
4 Copper Booze  (9.6)
5 Libertongo  (9.5)
6 Rainbow Connection  (9.5)
7 Onscreen 5k  (9.5)
8 Morph  (9.5)
9 Dawnfall V1.1  (9.5)
10 It's More Fun to Com..  (9.5)
Top Groups
1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Nostalgia  (9.3)
5 Censor Design  (9.3)
Top NTSC-Fixers
1 Pudwerx  (10)
2 Booze  (9.7)
3 Stormbringer  (9.7)
4 Fungus  (9.6)
5 Grim Reaper  (9.3)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.049 sec.