Looking for some general advice...
I've been using boost for a while, and I've written several small modules and function (eg: see this SO question) which I think cold be appropriate for inclusion in boost. I've been to the project pages to see about the submission process, but it seems like it's "be on the inside, or don't bother". I can subscribe to the developers mailing list, but I'm not sure I'm qualified to post there: I'm certainly not intimately familiar with all the various boost modules, and not nearly as well-versed in template meta-programming as the people actively participating.
Is there an avenue that I'm missing for "normal" people to send ideas for things which could be incorporated into boost? Or is boost kinda a "open in name only, unless you make it a full-time job" type of project?
I think that you shouldn't hestitate and go to boost-devel. Most likely your code will not be accepted, but it is very likely that you will be able to collect valuable feedback and learn a lot. People there will justify why it can't be accepted in the current form, or how the given functionality could be made more generic, etc. I think that overall it will be beneficial for you.
If you are not comfortable with boost-devel then subscribe and just follow it for some time. And few more personal comments about reading/following the list:
Find out who is who - some people are active only in very narrow fields, while others tend to have a lot to say in many different domains
Create some kind of filtering rules for new mails (the load of the list is rather heavy) - some mails are really not interesting
Observe the review process of the submitted libraries, critical comments, suggestions.
Subscribe to boost-devel, boost and boost-users - they tend to be quite interconnected. You can throw sprit, threads and ublas lists if you are interested in these projects.
I have been following the devel list for some time. I feel as you do: maybe I am not playing in the same league as these people, but nevertheless you do learn quite a bit from the discussions there.
During the time I have been there, I have found some kind of common pattern for submissions: first query for interest in the library, then offer the library for review. Beware of the licensing of your code: if it is not compatible with the boost license most of the people will not even give it a look. Spending time in the review of some proprietary code seems like working for free for someone else.
Also consider writting docs and publishing, make the library accessible in the internet and have others use/look at it. That will boost (no pun intended) your chances.
Why does your stuff have to go straight into boost ? Why not just put it "out there" first with a license you're happy with... if there's enough interest in it from users a "hey this should be in boost" might be the next logical step, or not.
I tried submitting my UTF-8 CPP library to Boost. Started by subscribing to their dev mail list and sent a couple of informal review requests, but felt it leads nowhere so I gave up and never submitted a formal review request.
Good luck with your submission.
Did you look at http://www.boost.org/development/submissions.html?
Related
Can anyone compare these two e-commerce frameworks?
I found this link, but I am not sure how outdated it might be. It mentioned that Satchless was still in the early stage. And at least according to this post from last year, django-shop was not production ready. Is it production ready now?
What I need is actually quite simple. I only need a B2C website (i.e. only me selling products to customers). The desired features include anonymous checkout, shipping cost + tax calculable, friendly products returning interface, paypal support. The code is hopefully easy to read and customizable (thus I will avoid Satchmo)
For Satchless: is it based on Satchmo, or a rewrite?
For django-shop: I noticed there is a giant ecosystem for django-shop. It implies that django-shop is highly customizable, but that might also imply inconsistent code design and implementation quality. And it looks like even paypal checkout needs a 3rd party extension?
Thanks again, I appreciate all your input.
Satchless isn't a rewrite of Satchmo, it's name is simply a reaction to the perceived poor quality of Satchmo's codebase. It's designed to be very minimal, but extensible. It's changed a fair bit over the last couple of years, so might not be a particularly stable platform choice (ie it's likely the API will continue to change in big ways).
There's also Oscar, which is more opinionated and feature-rich, but still designed to be extensible: https://github.com/tangentlabs/django-oscar
Disclaimer: I've worked with the Satchless guys (not on Satchless itself) and on Oscar directly.
You requirements sound like Mezzanine + Cartridge would be a better solution for you.
I'm a contributer to the Raphael project, and one thing we need is a central place for documentation and, IMHO, a good place for people to add examples of how to use the library to accomplish various tasks.
One of the contributers has done a great job of managing all this information himself so far, on his own personal site, but of course that means lots of maintenance for him, and makes it more difficult to make improvements, add new examples, and so on.
Is there a hosted wiki of some sort that supports allowing examples to be added? Ideally, it would allow the examples to be run; I know that there are some security questions about allowing contributed JavaScript to run, so I'd be fine with having an approval process if that's necessary, or worst case, at least an easy way to write example code and have it nicely syntax highlighted.
Anyone have a suggestion? Also, if this would be better posted to a different exchange, let me know; it's semi-programming related, but I thought it fit better here than on superuser.com.
There are places like sourceforge, Google's Code repository, and as mentioned in the comments, github.
I'm just now learning to programming at age 17. It's hard for me to talk to other programmers as I'm just out of high school (which means I can't take programming courses). I know that I write terrible code, and not like Jeff Atwood terrible code, my code actually sucks. So where can I post some of my code and get real programmers to review it. I know if I had a question I could ask it on StackOverflow, but I want to post a whole class and get a review on it.
The real problem here is that I'm not going to be writing the next great piece of Software. I'm going to be writing a really useless class, which will serve no other purpose than to teach me how to program. This code will never be used, ever! EVER! How can I get an advanced (or even intermediate) programmer to look at my code?
Thanks in advance! ;-)
Look to the open source community. There are plenty of existing and new projects that would love an eager (if inexperienced) developer to offer support.
Going this route offers two advantages:
You get to see great code in action and learn from it
Any changes you submit will be reviewed by an experienced developer and they will often give you excellent suggestions as to how to improve your code before it will be accepted
Start by choosing a project in your language (there are a bunch in c++) and check out the code. You don't need to understand it all, but you must be able to understand at least a portion of it.
If the project looks way to complicated, keep looking. Younger projects tend to have less code that you need to learn.
If you can't get great programmers to look at your code, do the next best thing: look at theirs!
Look for a bunch of code snippets that do the same (simple) thing. Before you look at them too closely, write your own code to perform the same task. Compare all of the snippets with your own (and each other!) and try to figure out the reasons for the differences.
I recommend looking for code from well established projects. Code from tutorials often ignores important details for the sake of simplicity.
Why don't you try RefactorMyCode?
I would try not to write useless code, but attempt to solve some particular problem. Your learning will be more advanced if you are learning in the context of a real-world scenario. It doesn't have to be a big business domain; could even be a game or a shareware utility.
As for getting your code reviewed, the open source community is a good way to go as The Lame Duck says - in fact you're guaranteed it gets some form of review if you actually contribute to a project. Other avenues to explore: your local C++ users' group, checking out a co-op program available through a junior college, or engaging someone in a company that sponsors interns.
I haven't tried sites such as RefactorMyCode as suggested by Gilad Naor, but that seems promising. And, yes, StackOverflow is a good place for bite-sized chunks of code. If you do that, explain what you are trying to do, and why you are trying to do it that way, and ask if there's a better approach. Good luck!
I think the best way to learn is the way I learned (I may be biased): trial and error. I just wrote programs all the time, teaching myself as I went. I'd write terrible code, and I would wrestle with making it do what I wanted. Often it would make me give up on that particular project. But on the next project, I'd take a different approach, and it would work better. Repeat ad nauseam. Once you know where the rough spots are in your designs, you'll be able to ask specific questions on places like SO, or, better yet IMHO, come up with better designs yourself. I independently invented all the major design patterns just through frustration at the solutions I'd created in the past. I think this gives me a valuable perspective, since for most people design patterns are just a "best practice", but I know the pain that comes with using other designs, and I can see signs of bad designs in code very easily (it takes one to know one). This last skill is one that I often see lacking in other programmers... they can't see why their design is deficient and they should use something else.
You could always try a site like Project Euler, where there are a whole load of problems that will test your skills and a whole bunch of solutions to those problems, submitted by others. Project Euler tends to focus on algorithms rather than higher level programming constructs, but I imagine that there are others in a similar vein.
Do something fun and don't worry too much about code style yet. I started out with BASIC on Commodore 64 without even realizing that there was such a thing as clean code vs dirty code. If I had worried a lot about that then, it might have hindered me from progressing. You always learn best when doing it playfully.
Maybe a bit late, but since StackExchange has Code Review, it worth the answer:
Code Review Stack Exchange is a question and answer site for peer
programmer code reviews. It's 100% free, no registration required.
Here is the link: Code Review Stack Exchange
As a hobby project I am trying to create a ROM (Diku-Merc based) derivative. (Now defunct) I would appreciate it if anybody has done something similar and has some useful resources to share or tips to offer. I'm finding that a lot the resources such as mailing lists are no longer active and many links are dead.
I've picked ROM because that is what I am familiar as a player, but the source is more complicated than anything I have come across and I wouldn't mind picking a code base that was easier to understand. Any recommendations before I dive in in earnest would also be appreciated.
As for mudding communities in general I don't know of much beyond the mud connector because I've always been in more of a user/player role than developer. A forgiving and active place where I can get answers to my questions is what I value most.
After extensive research I've decided to go with a tba code base. I may elaborate later but very broadly
Coding experience is more important than experience as a player and this has convinced me to abandon my roots. I wanted a well documented, reasonably modern, managable code base undergoing active development and this seems to fit the bill.
Anyways muds are truly a labour of love and you have to have a few screws loose if you plan to run one. Moreover the glory days have passed (it seems like there many muds shut down en masse around 2000) and in my opinion the community is largely inactive and fragmented. An exerpt from from some of the tba docs sums this up nicely:
So, you're sure you want to run your own MUD? If you're already an
old hand at playing MUDs and you've
decided you want to start one of your
own, here is our advice: sleep on it,
try several other MUDs first. Work
your way up to an admin position and
see what running a MUD is really
about. It is not all fun and games.
You actually have to deal with people,
you have to babysit the players, and
be constantly nagged about things you
need to do or change. Running a MUD is
extremely time consuming if you do it
well, if you are not going to do it
well then don't bother. Just playing
MUDs is masochistic enough, isn't
it? Or are you trying to shave that
extra point off your GPA, jump down
that one last notch on your next job
evaluation, or get rid of that pesky
Significant Other for good? If you
think silly distractions like having
friends and seeing daylight are
preventing you from realizing your
full potential in the MUD world, being
a MUD Administrator is the job for
you.
Anyways I don't have any high hopes for success, but this is something I will find interesting, improve my code-fu and will keep me busy for many years to come :D
There is no active ROM developer mailing list, so tba definitely is a better choice. There was some effort to clean up ROM with the RaM project.
Dead Souls sees active development as well (the main dev is a hero in my eyes for the amount of work he produces).
I would not recommend MUCK as the userbase is rather small. However that is not to say there isn't good work being done -- look up the user Valente on the code subforum of the wora.netlosers.com forum, as he's probably one of the foremost MUCK developers at the moment.
However if you thought that ROM was complicated I should caution you about tackling an established/canon codebase for any purpose other than getting a familiarity with mud servers. For actual development you may be better off with a barebones codebase such as NakedMUD (C/Python) or even something slimmer than that such as Socketmud (ports in many languages).
There are of course dozens of mud servers you can look at; all will be educational in some manner, but in the beginning stages it won't be obvious what is good practice and what is not. You may want to look up ColdC (similar to LP) and TeensyMUD (Ruby) to study. The author of Teensy, Jon Lambert, has a useful developer site up at http://sourcery.dyndns.org/.
However you'll find very experienced ROM and tba (i.e., Circle) developers at MudBytes, and I'll second Sam to say that is the most active mud developer site currently. It's a little surprising but in the last year there has been a significant growth in activity at MB. I think people are coming in from the fold so to speak and gathering at MB. There also is a good-sized code repository at MB as well.
Your other options are The Mudconnector which you already know, Top Mud Sites which has a somewhat smaller crowd of mostly developers (typically of established and long-running muds), and Mudlab, which is much quieter but usually with a good signal to noise ratio. MudGamers is an interesting new site with a fairly quiet forum, but a new approach to creating a more contemporary-looking portal for playing muds.
Not to be overlooked is the archive for the old mud-dev mailing list. There is a staggering amount of information to be gleaned there. The raw archive can be found at muddev.wishes.net/. Richard Tew also has done some noble work in combing through old usenet archives to find valuable mud development related threads, which you can find through his mud tag at posted-stuff.blogspot.com/search/label/mud.
I should note that many muds use the IMC chat network to link muds (MB has a portal to this as well on the front page of their site). Once your mud is running it can be useful to get on IMC if you're in need of real-time chat to fix a problem (of course, there are many IMC channels and you'll want to choose which one you use prudently).
Despite the fact that muds today are niche at best and unheard of at worst, there is no shortage of new muds in development. They offer a design and programming challenge that is still accessible to the solo developer, unlike any graphical game of equal size or complexity.
Furthermore you shouldn't be discouraged if it feels like you'll never release a playable game. Like many larger projects you may start and abandon it many times over, but you'll be building proficiencies across a wide spectrum of programming skillsets and applications -- not many projects will allow you to take such a whole systems approach. Good luck!
An active community seems to be around for the Dead Souls MUDlib
http://en.wikipedia.org/wiki/Dead_Souls_MUDlib
I was an old player of Nightmare LPMud which sadly disappeared. I'm not much in for the coding of these MUDs, but I have been following this community loosely just due to so many positive MUDding memories.
Take a look at Nameless MUCK. It's a solid piece of software.
First concentrate on getting or finding a solid Telnet Socket library going, this is generally the main protocol for a MUD.
Next, create a FULL list of features that you want to implement, you should probably get some sort of feature or bug tracking system setup (even if it is a spreadsheet). Then prioritize the features based on dependencies of other systems.
Check out http://www.gamasutra.com for some architectural discussions on creating games in general, creating basic AI, character systems, and multi-player games.
Once you understand the theory, it is just a butt load of programming to build in everything you want to support.
I'd make the MUD engine abstract enough to run behind both a terminal client, a web-based Ajax client, and maybe stand-alone clients - i.e., don't tie the front end in with the actual game logic. I'm not averse to a MUD actually using a decent font for the text, and real graphics (as interstitials or to make notes on the bulletin board look like notes, etc), not in place of the text based interface) where necessary instead of ASCII, etc.
You might also want to have some MUD script file converters into your own format, so that you don't have to spend ages creating zones.
I find the problem with MUDs is that there is too much emphasis on killing NPCs, and not many puzzles or other interesting aspects. So a more interesting, story-oriented (possibly to the extend of sharding zones for single-player or single-team use) engine could be a nice feature to have.
I will take this opportunity to recommend MudBytes, which is probably the most active MUD developer site available right now.
Last term (August - December 2008) me and some class mates wrote an application in C++. Nothing spectacular, it is an ORM for Sqlite3. We implemented some stuff like reflection to make it work and release the end user from the ugly stuff. Personally, i think we made a nice job, and that our ORM could actually be useful for someone (even though its writen specifically for Sqlite3, its easily adaptable for oter databases).
Consequently, i`ve come to the conclusion that it should be published somewhere (sourceforge most likely) as an open source project. But, as it was a term project, there are some things that need to be addresesed before doing that. Namely, it has some memory leaks that should be fixed, and some parts of the code could be refactored to make everyone´s life easier in the future.
I would like to know more experienced C++ programmers opinion on some issues:
Is it worth rewriting some parts to
apply new techonologies (for example,
boost).
Should our ORM be adapted to latest
C++ standard? Is there any benefit in
doing this?
How will we know when our code is
ready for release?
What are the chances that this ORM
will be forgotten into the mists of
the internet? (i.e is it worth
publishing it beyond personal pride
as a programmer?)
Right now i can`t think of many more questions, but i would like to read on similar experiences.
EDIT: I should probably translate my code + comments to english right? (self question)
Thanks in advance.
I guess I am "more experienced" with regard to your particular question. I co-developed an open source web application language & template system a lot like ColdFusion back in the early days of web design before Java or ASP were around. You can still see it at http://www.steelblue.com/ if you are interested. It's still used at the company I was at when it was developed, but I don't think anywhere else.
What I found is that unless you are already well connected and people are watching what you are doing, getting people to use your open source code is just about as hard as selling somone your closed source program. You really need to advocate for your project and it should have some kind of unique selling proposition that distinguishes it from the compitition.
So, that's the unsolicited advice. Here are some specific answers to the questions you had...all purely my opinion, of course.
I wouldn't rewrite any code unless you have a featuer you want to put in. That feature might be compatibility with a specific platforms or compilers. It might be to support a new db datatype or smarter indicies or whatever. If you are going to put some more serious work into the applicaiton, think about a roadmap of what you can realistically accomplish in the next iteration and what choices will make the app the "most better" at the end of your cycle.
Release the code as soon as it is usable for a specific purpose, any purpose. Two reasons. First off, there might be someone who wants it for that purpose right now. If it's not available, they will use something else. Also, if it's open source, they might contribute back to the project. Second, the sooner you find out how much people want to use the code, the better. Either it will be more popular than you expect and you can get excited about continuing the development....or....you will find that no one is even visiting your web page to see what you've got. In either case, better to know sooner than later what people really want from your project so you can take that into account when planning new releases.
About the "forgotten into the mists." I think most projects are. I don't want to be a downer, but looking at Wikipedia, there were 5 C++ ORM tools popular enough to get mention and they were all open source. As I said above, unless you can sell your idea to people, they are going to go with another proven open source solution. For someone to choose you over them, three things have to happen: 1. They need a feature you have that the others don't. 2. They find your project web site and it demonstrates the superiority of your code. 3. They trust your code enough to give it a shot.
On the other hand, if you are in this for the long haul and want to continue development thigns get easier over time. Eventually the project will get all the basics covered and you can start developing those new featuers that aren't in the other solutions. Also, the longer you are in active development the more trustworthy the project will seem. Finally, you will get more experience in the nitch. 2 years from now you will be better positioned to say where your effort will have the most impact on bettering the project.
A final thought: If you are enjoying it, learning from it, and it's not getting in the way of you keeping food on the table, it's a good use of your time.
Good luck!
-Al
Regarding the open source part:
If you really want to make it an open source project, you really should publish it regardless of it's current state - fully working and debugged - or half working and full of memory leaks.
Just, if it's state is bad, make sure to document it, and give it a suitable version number (less than one?). then others may view your code, suggest improving, join your team, etc...
My--rather random--thoughts on the matter (in the order I think is most important):
How will we know when our code is ready for release?
Like Liran Orevi said: if you're going open source release early. Document it reasonable well, and take the time to provide a road map of planned or hoped for future improvements (these are a invitation for people to help you, so note which ones have no one working on them).
Is it worth rewriting some parts to apply new technologies (for example, boost).
Should our ORM be adapted to latest C++ standard? Is there any benefit in doing this?
SQLite relies on a fairly limited base. Maybe you don't want your tool to demand a much heavier environment. If the code in not currently a tangled and unmaintainable mess, you might want to avoid boost and newest frills. Once you have a stable release (1.0 at least) you can starting thinking about the improvements that can be made for version 2.
What are the chances that this ORM will be forgotten into the mists of the internet? (i.e is it worth publishing it beyond personal pride as a programmer?)
Most things end up in the big /dev/null in the sky, and there is only one way to find out... If it goes anywhere at all, you win. If it doesn't it was a modest investment, and maybe you learned something while you were at it.