I'm looking to implement my own bug tracking database. Could somebody point me to the database table layout diagrams of any of the many tracking databases already in existance. I've come up with most of my requirements, and its simple for the most part, but I want to get an idea of what other people thought was important and how exactly they accomplished certain objectives.
FogBugz has the ability to let you export your bug database in a MySQL or SQL Server format. You could then look at the export and see how the data is structured.
I'm sure there will be missing tables that are built in to the app, but this will give you a starting point.
The other option would be to simply go look at the code for the numerous OSS bug tracking options out there and see how they do it. Trac and Bugzilla would be a good place to start.
(hell, simply installing either of those and looking at the DB structure with something like PHPMyAdmin would probably take all of an hour and should give you a great place to start)
Related
I'd like to ask is it smart enough to ship a web service/product without creating any CMS?
I mean in order to ship it faster and get some feedback from users it will be smart from my point of view to ship it w/out CMS and build it as you go but Im afraid from technical point of view - would it create any big problem that would be painful to solve?
Tnx.
Well, it depends on what you expect from the website. Should it be only a one-time web presentation, I think it might be okay to ship it without a CMS. I would also consider it fine if you didn't want to run a database for whatever reason (as most of the CMSs use database).
If the product is meant to be more complicated, it's definitely easier to start with CMS than to hack it in the product later.
However, if you decided for the latter way, you might find CouchCMS interesting. Though I haven't tested it myself, it looks very promising and easy to inject into an existing website.
I wanted to know if anyone has been using AirBnB Rendr and is it stable and ok to use in commercial projects or is it still changing a lot?
I'm developing a website which can run both client and server based, this mean I need to be able to render pages and widgets server and client based.
The server is running Node.js, dust.js and has custom server based code to render the pages and widgets on the server side. I need to pick how to handle it on the client side.
Naturally I want to try and not repeat code, but obviously the client is different I can:
Keep my current page based server rendering and develop custom
client side code.
Use backbone.js on client side and keep my server based code the
same.
Use AirBnB rendr that is based on Node.js and backbone to use the
same code on client and o server. AirBnB Rendr Library
I like the 3rd idea very much, but I'm looking for some input from you guys.
Has anyone used it? any experience with it in terms of stability and/or how often their api changes etc?
I've just started playing around with Rendr. If I ignore the learning curve and oboarding friction, I like it a lot and I plan to write my next large production app using Rendr.
Unfortunately, as bababa listed above, the documentation needs a lot of work. There is an explanation of how Rendr works in its README and the example app's README but beyond that you'll need to source dive in order to figure out how the gears are turning. Currently, there is no forum for questions (other than stack overflow :D) and I've had a hard time figuring out its idioms on my own.
Despite all the struggles, I finally see the light and I'm starting to understand why Rendr is so powerful.
tl;dr - If you're willing to source dive and figure out your own workflow, I would suggest using Rendr. Otherwise, I would recommend going old school by writing a traditional client app with a more mature library. (is it too early to say that? =X)
Well given AirBnb is a successful commercial enterprise, there's some validation that the library works well enough for them. This question is probably best answered by watching their github commit log for breaking changes. Given backbone is 1.0 and essentially stable at this point, rendr will probably quickly stabilize, but honestly your fear of instability is probably unjustified. I think rendr looks compelling and although my current project is using a very similar home-grown solution, I would consider using rendr in a future project or even porting our code to rendr. "Stability" per say is much less important to the web development community compared to other situations like packaged or embedded software.
I used (tried to use) and Rendr on a project and gave up. There are just to many limitations (currently) and the lack of documentation doesn't help. I ended up need to rewrite the source code to accomplish some things I would consider trivial with other frameworks, such as passing multiple collections to a view. It just wasn't possible (at the time I used it) and that was a deal breaker. Not being able to pass a collection of categories and results to a page was to much of a limitation.
I have no doubt it will eventually be ready for production use, but right now I would say unless you are an engineer at AirBnb and know how to hack the source then no, it's not ready.
If you really want to know if it will work for your needs, take a look at the issue list on github. That will give you a good idea where the projects at.
I am trying to create a complete session managment in nodejs for logins, chat sessions etc.
I googled a lot and every solution that i got was with some framework/module. I don't want to use any module/framework. I would rather like to build my own solution for this:
So this is the plan:
I will set a session cookie on the client machine (yet to figure out how)
For each cookie, i will be maintaining a unique id in the database instead of files as is the case with php (i am using mongodb)
When a user opens the application, a cookie will be set, a entry will be made in database and corresponding information from the db will be fetched.
I am yet to lay a concrete plan for this. I wanted to know whether doing it this way is a good idea? i read somewhere....'Real men don't use any framework. They make everything on their own' :P
Please correct me if i am on a wrong direction. M just starting with these things....
I'm not aware of any node.js frameworks that are closed-source. Just pick one that seems to do what you want to do, download it, and study the source code to see how the developer implemented it. Then come up with your (perceived) improvement on how they did it. You'll probably find that implementing session management involves a whole bunch of nitpicky details that were never obvious to you.
Ignore all the above advice if this is a school assignment where you're not allowed to look at related code. If that's the case, I pity you because you have an incompetent teacher.
Is there a tool that I can give a few people access to so that they can quickly modify the contents of our database? I'm looking for something easy to use and general purpose.
phppgadmin is going to be too complicated for some of the people that will be using it. I really like the django admin, but some of the constraints that Django brings are unacceptable. Something functionally similar would be great, I really do like how it works.
Have your tried using open office? you can get the postgresql driver here: http://dba.openoffice.org/drivers/postgresql/index.html
the you can create a quick form for anyone to add/delete query the database really easy.
and it's FREE to boot!!
I really like EMS's tools: http://www.sqlmanager.net/
They have for various RDBMSs, but they might be too complex for your intended use case.
You really need to state your platform and actual intended use (for instance, why is Django admin unacceptable?)
You can take a look at squirrel-sql.
I'm building a website that will be an open-source, user-contributed content kind of thing, and I think if developers had access to nightly production SQL dumps, they'd be more likely to check out the code from github and play with it.
In line with that idea, I'm considering either:
Not collecting private user information at all, using open-id for accounts and making heavy use of memcache for things like session authentication.
Anonymizing sensitive data before publishing
Sometimes I get carried away with "wouldn't it be cool if...?" ideas, so I'm hoping for a sanity check here. Any obvious flaws in either approach? Is this a sane idea?
Speaking generally, I think you should do both. Any private data you collect is simply a liability for you, and not just because you intend to publish your databases. The less you can collect, the better.
By the same token, however, you probably realize that it is not just IDs and passwords which are sensitive. Remember the AOL search data leak? Or the Netflix database publication? Even without having IDs, people managed to figure out the real identities of some of the accounts, simply by piecing together trails of user behavior, and corresponding that with data from other places. Some people are embarrassed by their search histories and their movie rentals. Go figure.
Therefore, I think the general rule should be to collect as little as possible, and anonymize what is left. Even if you don't store the identity of the person corresponding to a certain account, you may want to scramble what the various logins did.
On the other hand, there some cases where you simply don't care about this kind of privacy. In Wikipedia, for example, pretty much everything you can do on the site is public anyway. At least, everything which gets recorded in the database. If the information is already available through the API, there is no point in hiding it in a database download.
In addition to collecting less data and anonymizing the data you do collect, you could add a bit/flag for the users to select whether their data is included or not. You could make it a CC license flag to give users the warm'n'fuzzies while filling your need.
Sounds like a pretty good idea. The one thing you have to be careful with though is security, since hackers will know the exact schema of your DB. Although this isn't impossible to deal with, just look at most open source projects. But you will need to put a little extra emphasis on security since say a potential SQL injection is now made much easier.
Another thing is to make sure doubly that the sensitive data is anonymized. Also, some people may (wrongly) try and claim their copyrights on user submitted content is being violated, so you may want to specify a CC license or something just to make everything extra clear and prevent future headaches (even if you're right anyway).