Does anyone know if there is a libjingle developer forum?
The link provided at https://developers.google.com/talk/libjingle/index under "Support" throws a "You do not have permission to access this group. (#418)" error.
Other places I could find are http://code.google.com/p/libjingle/issues/list, but that is only for bugs. And the activity at Stackoverflow seems low.
I was going to ask the same question, and this question has been open for 2 months, which makes me think the answer is no. Also, I'll add that the link to google talk help center on the google talk blog goes to archive.org! I searched for other google groups that cover libjingle and they are filled with spam.
Moreover, the current compilation instructions for Mac OS X require a lot of work (I documented this here: http://blog.bjornroche.com/2012/09/compiling-libjingle-on-os-x.html). So I'm guessing this means google is quietly reducing their level of support for libjingle.
I think the best place to get support is right here.
I mailed one of the google developers and he told me that libjingle does not have a specific forum. He suggested we try the WebRTC mailing list instead
https://groups.google.com/forum/?fromgroups#!forum/discuss-webrtc
Since libjingle is effectively a subset of WebRTC, and WebRTC has a more active community.
Although if you have an issue, you can add the issue to:
http://code.google.com/p/libjingle/issues/list
Related
xUnit++ isn't the same thing as xUnit, and google doesn't point me to any good documentation. The xUnit++ site has a Wiki, with about five pages of general stuff, but no real specifics and no tutorials.
Does anyone know of any relatively complete, or detailed, documentation of xUnit++. Also, if you know of any tutorials, that would be great!
Thanks!
At the moment, there isn't. I opened an issue about this on the author's homepage over a month ago. The link is here.
https://bitbucket.org/moswald/xunit/issue/13/tutorial-and-quick-start
It can be assumed that he's busy because good programmers are usually swamped.
I would suggest making a bitbucket account to comment on the issue, or asking the author to move his repository to something like GitHub, where the community would take care of the rest of the work for him.
It might be a little bit difficult because he is currently using mecurial for his version control.
Not much of an answer, but there are other people looking for the same information as you.
[Change 2016-05-10]
I started using The Catch Framework for doing unit test in C and C++ approximately 2 months after answering this question. It is fairly well documented and in active development on GitHub. It might be worth a try.
It is my understanding that TED likely is not looking at making a BlackBerry App. I have a few frameworks I've created already for parsing various types of API's/feeds/services and would like to know if there is a way for a third party developer to make a TED app. I've heard mention of an API via the Googles but cannot find it.
I know this is quite old, but I just came across it. I was searching for an API for TED Talks as well, but was unable to find one. They have announced that they'll open up the site with an API, but I don't know when.
Instead, I decided to use the XML RSS feed, which is easily parsable. It's only usable for the latest talks and you naturally can't do any server-side filtering, but if that's good enough for you, you should definitely check out the feed:
http://www.ted.com/talks/rss
There's also the higher definition version of that feed:
http://feeds.feedburner.com/TedtalksHD?fmt=xml
There is an unofficial API for all ted talks details (gathered from youtube and ted.com)
its updated weekly with the data
http://market.mashape.com/bestapi/ted
supports:
get talks by name
get talks by speaker
get talks by description
get talks by transcript / search transcript
and looks like they publish more end-points from time to time
If you guys are still looking for something, I just open-sourced about 5400 hundred TED talks (TEDx, TED, TEDEd). Check it out and build something cool.
https://github.com/saranyan/TED-talks
A few colleagues and I created a simple packet capturing application based on libpcap, GTK+ and sqlite as a project for a Networks Engineering course at our university. While it (mostly) works, I am trying to improve my programming skills and would appreciate it if members of the community could look at what we've put together.
Is this a good place to ask for such a review? If not, what are good sites I can throw this question up on? The source code is hosted by Google Code (http://code.google.com/p/nbfm-sniffer) and an executable is available for download (Windows only, though it does compile on Linux and should compile on OS X Leopard as well provided one has gtk+ SDK installed).
Thanks, everyone!
-Carlos Nunez
UPDATE: Thanks for the great feedback, everyone. The code is completely open-source and modifiable (licensed under Apache License 2.0). I was hoping to get more holistic feedback, considering that my postings would still be very lengthy.
As sheepsimulator mentioned, GitHub is good. I would also recommend posting your project on SourceForge.net and/or FreshMeat.net. Both are active developer communities where people often peruse projects like yours. The best thing for your code would be if someone found it useful and decided to extend it. Then, you'd probably end up with plenty of bug fixes and constructive criticism.
You might get some mileage by posting the code out in the public space (through github or some other open-posting forum), putting a link here on SO, and seeing what happens.
You could also make it an open-source project, and see if people find it and use it.
Probably your best bet is to talk to your prof/classmates, find some professional programmers willing to devote their time, and have them review the code. Like American Idol-esque judging, but for your software...
As #Noah states, this is not the site for code review. You may present problems and what you did to overcome those problems, asking if a given solution would be the best.
I found a neat little website that might be what you are looking for: Cplusplus.com
What I am looking for is a tool that easily or automatically sends coldfusion error messages to their system.
Then I can use the web-based interface, to manage priorities, track who fixed what and so forth.
But I want to use this to help us deal with errors better, but also to show the importance of a bug tracking system to my fellow works.
System Requirements: Apache, Windows, Coldfusion 8 Standard, Sql Server 2005.
Financial Requirements: Free or Open Source
Goal Or Purpose: To encourage my fellow workers to want and use a bug tracking system.
Does this re-write make more sense?
Thanks
Craig
Wiki has a list of issue tracking software, maybe this list could help.
http://en.wikipedia.org/wiki/Comparison_of_issue_tracking_systems
You may be able to find a hosted service and use either email or web services to create the ticket using onError. With that said, a simple issue tracking app could be created for your site using the same DB used to drive the content. 2 or 3 tables would take care of the data storage and you're already using CF so the application layer is already there.
HTH.
I have been heavily using this type of a setup for several years by email only, and the last 3 years with a Bug Tracking Software.
I must say, the bug tracking software has made my life so much more peaceful. Nothing is left, forgotten, or slips through the cracks. It's easy to find trends in errors, and remember "all the times" it happened.
Our setup is like this:
1) Coldfusion + Appropriate framework with error reporting - It doesn't matter what you use. I have used Fusebox extensively and am making the transition to ColdBox. Both are very capable, in addition to Mach-II, FW/1, Model-Glue, etc. The key part you have to find in them is their ability to catch "onError", usualy in the application CFC.
2) Custom OnError Script - Wherever an error occurs, you want to capture the maximum amount of information about that error and email it in. What we do is, when an error occurs, we log the user out with a message of "oops, log in again". Before logging them out, the application captures the error and emails it to Fogbugz. Along with it, at the top we include the CGI variables for the IP address, browser being used, etc. Over time you will find the things you need to add.
3) Routing in Fogbugz. A 2 user version of Fogbugz is free, and hosted online. There are two main ways to submit bugs. One is to email one in at a time. So if an error happens 2000 times, you get 2000 emails, and 2000 cases. Not always the best to link them together, etc. They have a feature called BugzScout, which is essentially an HTTP address that you do a form post to with cfform with all of the same information you would have put into the email. There's plenty of documentation on this and something I've always wanted to get around to. I had a scenario of 2000 emails for the first time happen a few weeks ago so I'll be switching over to this.
Hope that helps. Share what you ended up doing and why so we all can learn too!
I'm surprised no one mentioned LighthousePro (http://lighthousepro.riaforge.org). Open source - 100% free - and ColdFusion. As the author I'm a bit biased though. :)
Hard question to answer not knowing what kind of restrictions are there? Do you have any permissions to install anything? Also most bug-tracking systems require some kind of database support.
I have a suggestion. You can put in place a basic bug-tracking system, that just allows people to create tickets, and allows you/someone else to close it.
More Windows based tools are mentioned here
Good open-source bug tracking / issue tracking sofware for Windows
Any reason why coldfusion specifically?
I really like Fogbugz from the makers of Stack Overflow. For one user it's quite reasonably priced. I enter some bugs manually and have others emailed in.
A lot of bug tracking software will expose SOAP methods for entering data into them.
For example, we used Axosoft's OnTime and that exposed some WSDL pages that I consumed in my application. I was told that Jira did as well.
There are few in CF411 list: Bug Tracking/Defect Tracking/Trouble Ticket/Help Desk Tools Written in CFML
We use HopToad. There is another bug-tracking app called LightHouse that integrates with HopToad so you can easily create a [bug] ticket from an incoming exception. HopToad has an API of which there are many clients, you want the CF based one:
http://github.com/timblair/coldfusion-hoptoad-notifier
Even if you dont use HopToad and you end up using a different service or roll your own, if you needed to write your own API client you could leverage the code or pattern(s) of the above HopToad client.
A lot of good information from everyone, and I really do appreciate the efforts given. But not the answer i was looking for. Which maybe means, that what i want does not exist, yet.
So i may have to roll my own solution...Or maybe integrate with another existing app...
Thank You all.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I was recently put in charge of the wiki for the development team. The wiki is still in its infancy, so I have a lot of room to work with. It goal is to house internal to the development team. Currently, the main piece of information that the wiki holds is Coding Standards.
What are some best practices your dev team uses for its internal wiki?
What information is important to have on a dev wiki?
If you were to go to the wiki for your dev team what information would you expect to see?
Is there some information that shouldn't go on the wiki even though it seems like a good idea?
-- edit --
Also, is there a good way to organize the information? ( such as by layer ( data, ui), by porject, or other)
Introduction to the source base for new programmers
General documentation (not the API documentation per-se, but more tutorial like things)
Lists of staff / who's doing what and how to reach them
Notes / resources / articles that explain concepts used in the software
Documentation of the build process and the filesystem layout of the codebase
Other things I usually put up there are
Planning / todo lists
Information that is interesting for others to read
Everything else that I feel should be shared
We had a development wiki and it was a great tool. We used it for everything!
When brainstorming new ideas, we'd capture them on the wiki. The low friction nature of the wiki made it easy for anyone in the organization (we were a small startup) to add ideas as they thought of them. We had a high level "brainstorming" page which linked to detailed pages containing a thorough description of each idea.
For each iteration, we'd "move" feature idea items from the "brainstorming" list to the feature list for that iteration. The details of the feature were flushed out to include design and implementation details.
As features were completed, the iteration page became our release notes page - which also included the release tag from our version control system.
We had a bug page that worked very similar to the feature pages. Bug fixes were added to the iteration/release pages as they were worked on/complete.
We also created our user documentation on the wiki and exported those pages it with the release.
As time went on. This tool was viewed more and more valuable. We wound up creating new wikis for different the products the company was working on.
I hope you find your development wiki as useful as we did!
Wikipatterns is a website dedicated to documenting best wiki practices. They also describe anti-patterns and talk about ways to deal with them. I read their book and it was a great asset for me to get a wiki off the ground in a 150+ person organization.
One thing that we stress on our dev wiki is that it is updated when things change.
We don't want our wiki that is intended to provide information and be a central source of collected knowledge to become so out of date that it is useless. As the code is updated, developers are requested to update any related information on the wiki.
Other than Coding Standards, we keep tips and tricks for working with our code base, setup information for new hires, and general environment information.
The hardest part is getting developers to use your wiki. I have some long standing suggestions here: http://possibility.com/wiki/index.php?title=GettingYourWikiAdopted
Getting a Wiki Adopted is Tough
Have a Champion
Remove Objections
Create Content
Enmesh the Wiki In Company Processes
Evangelize
Don't Give Up
Consider Not Using Wiki For Conversations
Just Do It! Don't Wait For a Budget
Have a Transition Plan
Promoting Your Wiki
One good practice is to have the entire documentation and source code for each build available through your wiki. Then developers will go to wiki to access build info and that makes it invaluable.
Wikis can be a valuable resource for software development teams but they are not a silver bullet. It is all too easy to create a Wiki that would rapidly fall into disuse or become grossly outdated.
In my opinion, the key to a successful Wiki is getting the entire team on board. That means getting people away from other resources (and in particular email archives) as knowledge repositories, and offering some incentive for people to contribute.
However, it's also important to not be a format czar: If you have a lot of documents that you generate in, say, MS WORD, it may be ideal to do them all in Wiki format but that takes time and may be annoying if you have diagrams, documents, etc. In those cases, it's better to compromise and let people keep it in word format, as long as the only way to access the newest version is through the Wiki.
If you're not a manager, you need to get a manager on board because it would require some "enforcement".
There has been accumulating research and experience on Wikis and their use in software engineering. You can search the ACM digital library, for example. I am a coorganizer of an annual workshop on wikis for SE and we had several interesting experience reports and there are additional materials in the international symposium on Wikis.
Burndown charts
common setup information for development environments (nice for when new people start)
Specs
Known issues and workarounds with development tools
Come up with some kind of style guide, and teach others how to style stuff. When I was in charge of a corporate wiki, all of the other developers would just write crummy prose that was barely formatted, and looked terrible.
Keep away from things that require discussion. I tried shoehorn in a book review section, but it was too difficult to have others comment on things.
Examples of in house libraries are good. And/or "storyboards" walking a user through a process when MethodX is called.
What are some best practices your dev team uses for its internal wiki?
Make it look nice. I know it doesn't sound important, but if you spend a little time branding it pays off in terms of people actually using it. And uptake is key, or it will just wither and die.
What information is important to have on a dev wiki?
General information about a Project, milestones, delivery dates etc.
Summaries of design decisions/meetings. Important so that you don't re-visit the same areas time and time again.
HowTo guides for general development of current projects (for example, how to develop a new Plugin)
If you were to go to the wiki for your dev team what information would you expect to see?
Project information, who is working on what etc. Design decisions. Also best practices and links to useful sites.
Is there some information that shouldn't go on the wiki even though it seems like a good idea?
Low-level task lists tend to fluctuate and not be kept up-to-date, and can be misleading.
Also, critical communications between departments are better suited to e-mail, THEN the conversation can be copied to the wiki. It's too easy to ignore it otherwise!
Remember that a wiki is interactive. If you're thinking about publishing, as in publishing burndown charts, then you're not thinking far enough. Distributing that information is only part of it.
For instance, rather than having a "Current Burndown Chart" page, create a page for "Burndown Chart for Week of 10-27-2008" and then encourage people to comment on the chart, and what it means, and why you did so poorly that week.
We house and inhouse team wiki. And there we put all the necessary information for each project we are developing:
repositories
addresses for virtual machines
passwords
project documentations
project overview
project status
and anything else we fill needs to be written on a project. And it is the most useful web application we are running (besides Mantis) . On more general pages we put a definition of every taxonomy we are using, general project guidelines, polices, coding and developing practices we use.
It is there, it is simple and effective and I think every team should have one of those.