Another post about the project

root

Site Team
Staff member
Messages
8,185
Location
UK
Right, as you know there is a group of people who have sort of loosly agreed that we're going to make something for this forum.

the last two threads have concentrated on who wants to be involved and the kinds of projects that we'd like to do

http://www.computerforums.org/forums/social-lounge-off-topic/project-220762.html
http://www.computerforums.org/forums/social-lounge-off-topic/project-thread-updated-220928.html


so the decisions/consensus so far is:
we'll be doing a software project.

and that software project will be some blogging software.

I think that there are only four more things to discuss:

What programming language will this be created in?
What license will this software be created under.
(ideally something open source, but perhaps someone who fully understands the various license types could make a suggestion)
What source control software are we going to use?

and finally, what features should be possible?

As a start :
My language of choice would be PHP

features: (this needs to be expanded)
I'd suggest an editor that was able to accept either plain text or HTML, also some may find it easy to write code that's used in forums, with square brackets etc, so why not have the editor recognise that style of formatting too?

A way to generate RSS feeds of the blogs being written on the software.


There have been a few offers for hosting. (which is good) so I think that we need to figure out who is doing the hosting. It might be good if of the people who offered hosting one could actually host, and another mirror to make sure that the hosting wasn't suddenly cut off for any reason

we'll also need to figure out a development environment server platform.

I would suggest that the best idea for this would be to create an installation of linux with the relevant software on it that can be run under either vmware player, (available for free on windows linux and Mac, or a disk image for qemu (available for windows/linux/mac and free open source)

that way we can all develop with the same extensions installed, same configuration files etc.then there should be no issues when one person says that the code doesn't run, or throws errors and it turns out that the person who submitted the code has some weird extension that allows it to work and warning information set not to display.

and I think that Bahawolf is right, lets not spend too long talking about this.
as soon as there is consensus as to what language is going to be used, and where source will be uploaded to, I think that we should start writing code.

Ideally that would happen this week?
 
I like it. I have a web server available that we can host the project on. It is a Linux server with PHP 5 and MySQL. I agree that PHP is the best choice for scripting language.

License should be GPL.

As far as creating the project, my knowledge of PHP is limited to pretty much using includes. I could design the UI for the back end as well as a theme for the front end.
 
Well what we could do is what I like to do for easy backup. Dropbox.

I have it setup on my websever that way I can edit a file and have it almost instantly available online.

We could setup a server for deployment (example.com) and a subdomain (bob.example.com) for testing. All on the same server, mirrored to a a backup server, synced via dropbox.

That also takes care of development issues with not having the right software, etc.
 
You guys are going to use some form of versioning system, right? :)

I hope so, as otherwise it'll be impossible to manage.

As for language choices, that should be one of the last things we discuss. First we should decide if the user-facing code should contain everything, or have the SQL related stuff in some kind of server architecture to keep the entities separate.
 
I'm in two minds about GPL.

the trouble with GPL is that it's a very strict license, if we form our work on the GPL then anybody who takes our work and improves it MUST also doso under the GPL.

it also because that if we were to take work from a different license type, say BSD license as a component that we wanted to use we'd never be able to release the software since GPL REQUIRES as a MUST that certain conditions are met, the BSD license would REQUIRE as a MUST that other conditions were met, and bringing things together might make them incompatible.

for now I'd happily go on saying that we will make this open source, but perhaps wait until later to figure out what license model would be best to use, (if we needed a component that was released under LGPL and that was irreplaceable then it would surely make sense to try to make whatever license we wanted to use compatible with the biggest part that we decided not to write ourselves?


RE keeping SQL stuff separate. if we were talking MSSQL server then yeah, stored procedures on the database server.
as we're most likely talking mySQL then I think that it'd be better to keep SQL in the code.
though permissions/connection sting details may be kept in a separate file.
(in fact *should* be in a separate file that's just included where necessary so that anyone needing to change DB parameters only needs to change them once!)


version software is surely something that we must have, but my experiences with version software is limited, so I have no real opinions on this.
 
In terms of licensing - obviously it's up to you guys, but I'd be tempted to say go with the GPL, and if you run into any problems along the way solve them when you come to it. Yes, it means that everyone who develops on top of it will need to use the GPL, but is this really a bad thing, considering that basically means they need to keep it open source as well?

Also, bear in mind that if you use another license, such as Apache or BSD, you won't be able to use a GPL library at all - whereas the other way around there's more flexibility. Combine this with the fact that there's a lot of decent libraries written in the GPL (arguably most decent open source libraries) and not choosing it places a heck of a restriction on what you can legally achieve.

Put it this way - I'm lead developer of a medium sized project at the moment, it uses GPLv3, and I've yet to come across a library I couldn't use because of a licensing incompatibility issue.

More to the point though, I think root is right in that licensing isn't necessarily something you need to get bogged down in right away at all. There's more important technical decisions to be made.

In terms of version control, I'd advise sticking with subversion - yes, you could argue that Hg or Git technically offer more features, but (especially with the latter) that comes at a cost of complexity. Subversion is perfectly stable for what I think you guys will need it for (no excessive branching), is the most widely supported, and possibly easiest version control system out there to get started with. If you choose to host the project somewhere like Google Code, you can always switch to Hg or Git later if you choose anyway.
 
RE keeping SQL stuff separate. if we were talking MSSQL server then yeah, stored procedures on the database server.
as we're most likely talking mySQL then I think that it'd be better to keep SQL in the code.
though permissions/connection sting details may be kept in a separate file.
(in fact *should* be in a separate file that's just included where necessary so that anyone needing to change DB parameters only needs to change them once!)

I wasn't talking about the stored procedures for the database management system (mySQL, MSSQL, Oracle etc) but the actual select and update statements that we would code. It's a lot cleaner, easier to read and arguably more secure to have the client code make a method, network or http request passing in the appropriate data as parameters over nesting the SQL right into the client code. This would allow us to create method that could then manipulate the parameters into the statements to allow for much greater code re-use and as I already mentioned, it's much easier to read.

The permissions/connection string could still be kept in a file with this kind of setup.

berry120 said:
In terms of version control, I'd advise sticking with subversion - yes, you could argue that Hg or Git technically offer more features, but (especially with the latter) that comes at a cost of complexity. Subversion is perfectly stable for what I think you guys will need it for (no excessive branching), is the most widely supported, and possibly easiest version control system out there to get started with. If you choose to host the project somewhere like Google Code, you can always switch to Hg or Git later if you choose anyway.

I've used SVN almost exclusively. I have a little experience in Hg and Git but still prefer SVN. I do have an SVN server that I can see about opening up to the group if desired.
 
Another thing you guys may want to look at on the setup side of things is Jenkins / Hudson. This can be set up with SVN to automatically rebuild / redeploy whenever a change is made and committed - really useful for having a consistent platform where the latest build in trunk can be tested.

It can also name and shame - if someone breaks the build, it can email everyone and tell them who it was ;)
 
Another thing you guys may want to look at on the setup side of things is Jenkins / Hudson. This can be set up with SVN to automatically rebuild / redeploy whenever a change is made and committed - really useful for having a consistent platform where the latest build in trunk can be tested.

It can also name and shame - if someone breaks the build, it can email everyone and tell them who it was ;)

Use that at work (although I don't use it to name and blame but others do). It's very easy to set up. I personally prefer Jenkins more, there seems to be a more active community around it.
 
Back
Top Bottom