Like many developers I read alot of articles of different code methodologies, patterns, blogs, examples etc etc along with trailing through github, codeplex etc for code samples.
I have used delicious bookmarks in the past to keep track of interesting articles and sometimes code snippets & repos. However this isnt working very well for me as I keep forgetting and also find it difficult to find articles in there.
So I am wondering what do others use to keep track of above? Would be interested to hear other developers opinions on knowledge and resource management?
i use my blog - http://www.acooke.org/cute - which is generated by email, so this is pretty much equivalent to sending myself an email with the URL, a useful title, and perhaps some commentary. one advantage of a blog approach is that occasionally people send useful commentary (isn't posterous an email-generated blog? that would be equivalent...)
i have also used a local install of mediawiki (the wiki that wikipedia is based on, but really any wiki would do - i chose that one so that it wouldn't become obsolete). but that's better suited to long-term things like clients, details of projects, etc.
Google email account
Create folder called code collection
Create filter for all emails received with subject "code collection" get placed into that folder
Find a bit of code you like? or even copy and paste the whole page into an email and send it to yourself with the title "code collection"
Then after time and accumilation of emails in that folder, you will be able to search your emails by the "code collection" folder for keywords - in effect your own personal google searchable code archive.
I been doing this GMail was released and built up a very nice repository of code over 3000 emails spanning lots of languages.
I also keep archives of all work projects, including creative and often make markers on backups to keep certain classes / functions.
We've just decided to purchase Google Apps for Business for a couple of users and are now running pilot for migration.
We have a certain issue, which we would like to see if it can be solved with Google Apps Script.
Suppose that the following situation applies:
At this moment we're in a domain and we have certain user templates set-up in documents such as a document for faxing and a document for memo's. These templates have application-logic behind them so the template gets filled in values for the users name, and branch office, ...
What we would like to do is replicate this behaviour in Google Drive, but I'm not sure what the best way is to implement such a feature.
Do we create a spreadsheet and in the script editor we write the full template from scratch? Or is it possible to have a template on the google apps account which we then can transform on open?
I hope I'm a bit clear of what we would like to achieve, but in case I'm not; do feel free to ask me more questions.
I hope to hear from you all!
Kind Regards
Your question relates more to a global appreciation of Google Apps than a script question... I'm not sure I should be answering here...
As a personal opinion I guess documents would be the best tool to get what you want. You'll have to create a couple of templates with personalization fields that a script would fill in with the 'logged user' data.
The document and doclist api are quite powerful and could also classify the created docs in folders and manage how they are eventually shared among users.
Depending on your abilities in javascript coding it can be anything between quite easy and really hard to build up ... :-)
I try to devote certain time everyday to learn new skills while also improve the older skills that I've gained. But, I'm not hitting the sweet spot where I learn what I want and get things done.
So, I was just curious to know how you guys spend time everyday and "hit the spot".
I use Google reader and just add more and more tech blogs as I find them. Then, I read them in the morning with coffee. This site provides quite a bit of education as well.
I read technical websites everyday. I like to use Google reader as well since it tracks what I've read and allows me to easily continue where I left off from any computer I happen to have access to.
I started out with the basics : Slashdot, Ars Technica
, and Dr. Dobb's Journal. These sites will frequently lead to other great sources of information.
When following sites like this using an RSS feed, you don't have to read every article that comes through. Just scan them over and read the ones that catch your interest. Without realizing it, you will store away alot of information that will pop back into your head when you encounter a situation that triggers it.
You won't necessarily be a master of everything you read but you will be at least aware of current developments and technologies.
The second part is to practice. I usually have some simple and enjoyable programming project on the go at home all the time. I may not actually complete anything useful but I use it as a basis to try out new things. Alot of times I will encounter a problem at work and find that I've already explored some of the solutions at home or at least thought about them and will be able to make a much more informed decision.
Tech blogs are a great way to find out basic information on new material and sometimes they will even have a more in-depth feature that can leave you with some take-away knowledge than just another tech headline.
What works best for me is to identify topics that I have read in tech blogs that interest me and then find sources that provide me with more advanced information on the subject. Then as the week goes by spend however much time needed to digest the information learning the material.
Just browsing tech headlines all day, in my opinion, won't leave you with any distilled information beyond basic advances in technology. Actually diving in and spending X amount of time each day learning material that is interesting to you will be infinitely better.
I find the key to getting things done is to manage distrations. I process email in batches only once or twice per day, and try to avoid phone calls, meetings and IM where I can. This leaves me bigger chinks of time available for development.
I learn new skills in a couple of different ways... Firstly reading a load of developmetn related tech blogs via an RSS reader. This allows me to absorb a continuous flow of new ideas without necessarily "learning" a lot, but saves me a lot of time on research later. Then when I run into something new, chances are something I've already read will be of assistance and I can dig in an "learn" something in more detail.
e.g. Through regular RSS reading I became aware that a significant number of javascript frameworks had been developed and it seemed to make more sense to use a js framework than coding DOM manipulation by hand. Later when I started a new project that was going to be heavy on Ajax, I was able to name a couple of frameworks off the top of my head,quickly pick one and really dig in and get to know it.
I have a Mailman managed list with years of history that I want to migrate into a web-based forum. Things it would be nice to do:
Keep the mailing list going for those who are used to and prefer it to a web interface, but have it integrate with the web-forum activity.
Take the web-based forum posts, and send them out to the mailing list.
I have run sites based on phpBB, Drupal, Simple Machines, etc., and am able to do a little bit of coding if that was what was required to integrate some package into Mailman, or replace it entirely. But I'm unaware of what is available, commercial, or open-source, that could accomplish this. I am also open to replacing Mailman, if the candidate package can perform its functions reasonably well and integrate well into its own forum.
Even if the phpBB/mail2forum option is using the older version, it is a nice option. OpenSceneGraph just implemented this for their long running mailing list, and it seems to work flawlessly. It's the only option I've seen that allows for forum posts and mailing list messages to work very seamlessly, and has the means to allow for tags to separate forum subjects from mailing list posts, etc.
Their v2 dev works with phpBB3, too - so if you're willing to live on the bleeding edge, that might be an option.
So far, here's what I've looked into:
Drupal, with its Mailmanager and Listmanager modules, though I've been having trouble turning on the IMAP feature so it can talk to my mail box (clients can access it fine), and the Drupal's forum module isn't really up to the feature level I'd like.
PhpBB, mail2forum, though it looks like currently it only works with the older phpBB version, so not really an alternative for me.
The only one that seems to really "work" is FUDforum and its maillist.php module, which integrates directly at the procmail level, nice. I can take all my Mailman archives and "formmail -ds" them directly into a chosen forum.
I've started a bounty for this issue, I'm looking for something, even commercial, that really integrates the email interface into the forum experience for the end users, particularly the handling of accounts. With FUDforum I'm still going to have to resolve the separation of the Mailman accounts from the FUDforum accounts.
I ran across this on the web: http://mail2forum.com/
I haven't used it but it looks promising and has both a 1.2 stable version and a 2.0 development version, so it's not a derelict SourceForge project with 1 developer and no commits, or anything :)
Theoretically my org may use it at some point in the next year or two, but we have to finish our own Listserv to Mailman transition first.
Well, based on what you've said (first, that you're able to do a bit of coding and second that FUDForum would work for you except for the issue of maintaining list membership, have you considered that:
Mailman stores its user information in a plain text file and
FUDForums stores its user information in a single sql table
The obvious solution would be to declare one of these master (probably FUDForum, since it looks as if it holds a proper superset of the Mailman info) and have a little script/cron job that copied changes from the master to the slave.
A passing note -- neither of these systems appears very secure (actually, they both look leaky as all get out) and combining them may well reduce the collective security even further. If you are doing anything even remotely confidential you should rethink your goals, and in any case you should take appropriate steps to protect your system from attack.
I know an SME which switched from the mailing list to phpBB!
If you want to keep your mailing list, you have also to maintrain it.
Finally the people I know diabled the mailing list service.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I work on a complex application where different teams work on their own modules with a degree of overlap. A while back we got a Mediawiki instance set up, partly at my prompting. I have a hard job getting people to actually use it, let alone contribute.
I can see a lot of benefit in sharing information. It may at least reduce the times we reinvent the wheel.
The wiki is not very structured, but I'm not sure that is a problem as long as you can search for what you need.
Any hints?
Some tips:
Any time someone sends information by email that really should be in a wiki, make a page for that topic and add what they put in the email. Then reply "Thanks for that info, I've put it into the wiki here so that it's easier to find in the future."
Likewise, if you have information you need to share that should be in the wiki, put it there and just send an email with a link to it, rather than email people.
When you ask people for information, phrase it so that putting such documentation in the wiki should be considered the default or standard: "I searched in the wiki but I couldn't find it. Have you put that info up there yet?"
If you are the "wiki champion", make sure other people know how to use it, e.g. "Did I go through how to create a new page with you yet?"
Edit the sidebar to make sure it is relevant to your work.
Use "nav box" style templates on related pages for easier navigation.
Put something like {{Special:NewPages/5}} on the front page, or recent changes, so that people can see the activity.
Take a peek at Recent changes every few days or week, and if you notice someone adding information without being prodded, send them an email or drop by and give them a little compliment.
As I mentioned before, a Wiki is very unorganized.
However, if that is the only argument from your developers, then invest some effort to create a simple index page and keep it updated (either do it yourself or ask people to link their contributions to the index). That way, the Wiki might grow into a very nice and quite comprehensive collection of documentation for all your work.
We've been using a wiki in some form or another for a while now, but it does take a while for people to get on board. You might find that you will be the only one writing articles for some time, but bear with it, other people will come on board eventually.
If someone sends an email around that contains information related to the project then helpfully point them in the direction of the wiki - and keep doing that - they should get the hint.
We have a SharePoint portal and use the wiki from there - we customised it with our own branding so that it "looks the part" - I really feel this has helped to improve the uptake of it.
Make sure that everyone is aware that the wiki is even more informal than email.... because there will be a "fear factor" that people may think anything they add to the wiki will be over-analysed.
I think most of the answers so far are spot on - the more you plug away at it yourself, the larger the body of useful information will become, so slowly but surely people will naturally start to use it.
The other approach you could use is this: Suggest that every time someone asks another team member a question about the project, they should answer the question as normal, but also add the answer to a section of the Wiki. This may take a few minutes extra, but it will mean that the next time someone asks the same question (which they inevitably will), you can save time by pointing them at the Wiki. This, in turn, should help people to start using the Wiki as a first source of information and help overall up-take.
You can't force developers to do something they do not have an incentive of using for; unfortunately wikis, like documentation (well, in fact wikis are documentation) rarely have any "cool" value for developers. Besides, they're already deep into dev work -- could you really bother them with a wiki?
That being said, the people who pushed for the wiki (e.g., you) should be primarily responsible for updating it, and you really would have a lot of work cut out for you if you're serious about it.
You might also try the ff:
It's not very structured you say -- a lot of people get turned off from ill-structured (hard-to-search/browse) wikis. So maybe you can fix that first
Maybe you can ask lead developers/project managers to populate it with things that are issues for them: things like code conventions and API design for your particular project
Lead by example: religiously document your part of the system. Setting a precedent may encourage others to do the same
Sell the idea of using the wiki to the developers. You've identified some benefits, share those with the developers. If they can see that they'll get something of value out of it they'll start using it.
Example advantages from What Is a Wiki
Good for writing down quick ideas or longer ones, giving you more time for formal writing and editing.
Instantly collaborative without emailing documents, keeping the group in sync.
Accessible from anywhere with a web connection (if you don't mind writing in web-browser text forms).
Your archive, because every page revision is kept.
Exciting, immediate, and empowering--everyone has a say.
I have done some selling and even run some training sessions. I think some people are turned off by the lack of WYSIWYG editing and ability to paste formatted text from Word or Outlook. I know there are some tools to work around these, but they are still barriers.
There are some areas where the wiki is being used to log certain areas, but people who update those are not doing anything else with it.
I will use the wiki to document my specialised area regardless as it acts as a convenient brain extension. When starting a new development I use it as a notepad for ideas that I can expand on as it progresses.
It would help if management would give it some vocal support, even if it is not made mandatory.
I have a hard job getting people to actually use it, let alone contribute.
One of the easiest ways to get people to contribute to a wiki, is to actually have them provide contents in a wiki-suitable fashion, i.e. so that whatever they post using their usual channels of communications (newsgroups, mailing lists, forums, issue trackers, chat), is basically suitable for inclusion on the wiki.
So that others (users/volunteers) can simply take such contents and put them on the wiki.
This sounds more complicated than it really is, it's mostly about generalizing questions and answers, so that they are not necessarily part of a conversation, but can be comprehensible, meaningful and useful in a standalone fashion.
For example a question like the following:
how do I get git to clone a remote repository???
Can be answered like this:
Hello,
Just use git clone git://...
But questions can also be answered in a less personal style:
In order to clone a git repository, you will want to use the clone parameter to git:
git clone git://....
What I am trying to say is that most discussions in a project can and should be easily used to become documentation eventually. With this sort of mindset, your documentation can actually grow rather rapidly. You only need to get people to keep in mind that useful information should be ideally provided in a fashion that is suitable for wiki inclusion.
I have witnessed several instances where open source projects started to use this approach to some extent and while some people (largely new users) complained that answers were not very personal, the body of documentation was increasing steadily, because other people simply monitored such discussions and started to copy/paste such responses to the wiki.
Basically, this is one of the easiest ways to get people to contribute to a wiki, without requiring them to actually use it themselves, the only thing that's required of them is a shift in thinking.
If the developers still need to maintain 'real' documentation (s.a. Word documents), I see no way to meaningfully duplicate that on a Wiki.
It does not make sense for people to write twice
Any duplicated data is prone to get out of sync, soon.
What my current customer has done is move all this to Wiki. So I only document once, and I do it on the Wiki.
This is okay. Working with Wiki is more tedious than with Word, but at least the doc is online and others can mix-and-match with it.
Another working solution (imho) would be to store docs alongside the source, on subversion. But then the merging system needs to be able to cope with rich text etc. as well. I don't know, if any solution for that exists (other than using HTML or LaTex, which actually would not be bad picks).
Find "sticky" items (sub-3 pg. docs / diagrams / etc) something that the team seems to be creating again and again & post it on the wiki. Make sure everyone has access to the wiki and knows its there - set up a notification mechanism if possible. With some luck, the next time they have to access, rather than dig it out of version control or their machines - they should hit the wiki.
If they still don't, try to see if the team has enough slack to actually use the wiki - Subtler issues may lie beneath their reluctance.
Take a look at the advice at http://www.ikiw.org/ Grow your Wiki
Just to add to some of the excellent advice being offered here...
As a dev in a small company that does largely gov't contract work in the 6-24 month range, I find that my time is often split between development and writing status reports (right up there with writing documentation, only worse!) Having a wiki to slap down unorganized thoughts and notes as we go along has made report-writing a lot less painful (not pain-LESS, but better all the same).
Further, if you're already in the Mediawiki world, you might want to look at SemanticMediawiki. It allows you to take the organization of your data to another level by semantically tagging it. That doesn't mean a lot on its own, I know, but I can tell you (for example) that it can drastically improve the relevance of the data returned from searches. It is definitely worth a look.
Generally good advice here. I'd like to add:
You really need a champion - someone pushing this to developers and management (without being pushy - that's a challenge!) and providing support & tutorials when possible. This person also needs to be a peer (so a fellow developer, not someone in a remote IT department) and really customer focused i.e. ready to make changes when requested.
Speaking of changes, some people here say wikis are unstructured. I disagree. Our MediaWiki installation is structured using categories, particularly with two extensions:WarnNoCategories (to require users to add a category when saving a page) and CategoryTree to show how all the categories fit together (this can be linked to from the sidebar). I've got more tips on how we keep this low threshold, if you're interested.