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 1 year ago.
Improve this question
I am unsure what to tag this under, but I'd imagine it's a question that's relevant to most developers.
Throughout my working day, I often come across snippets of information and knowledge that will come in useful again. These may be general coding examples, or else environment specific commands etc.
Typcially, I just store these in different text files, and then refer to these text files when I am in need.
However, this is awkward and difficult to search
One alternative I've considered is creating my own local Wiki and tagging such snippets under common tags, that I can easily search.
I'd be interested to know though how other developers manage such knowledge in a "pragmatic" way.
As above, TiddlyWiki seems like the best option here
I keep my notes in a combination of Evernote and Microsoft OneNote.
Evernote takes care of most of my note-taking while reading on the web. If you set up your notebooks in an organized way, and are diligent about tagging your notes when you create them, the built-in search makes that information available anytime, anywhere. Advantages:
Can group, sort and tag in as many ways as I want
Available on all my devices
Clipping articles and snippets is a breeze on Chrome with the
add-on
Simple interface
OneNote is brilliant when I'm working on my PC; it is more feature-packed than Evernote and the ability to free-form text and to paste in any other document is awesome. Wish it had the range of availability of Evernote; I wouldn't need anything else.
There is a very good knowledge management system at that is practising typing in the right keywords in google (or bing if you prefer).
I do it many times a day and have never had the urge to save anything, or even bookmark it, as it is easy enough to find it back if required, if not through your web browser's history by typing a similar query in google.
For progamming issues you may be better of using stackoverflow.com for your searches, but stackoverflow.com results are usually on top of your search result listing anayway.
I was using TreePad for that 6 or 7 years ago and it was great. The only problem was my computer crashed and I hadn't been backing up as I should have. So now I use Google Docs. The data isn't organized in the nice way that TreePad does, but I don't have to worry about backups and it has a search capability (although I have noticed a few glitches in the search before where it didn't find something I knew was there).
Related
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 3 years ago.
Improve this question
What are some good procedures to follow when handing a project to another developer, in cases of when the original developer will still be around for a couple of months to aid in the transition? Let's assume a medium-sized web application if a concrete example is necessary.
As a junior developer, I have gotten several projects assigned to me for maintainance that were written by others. I believe the easiest projects to continue are the ones where the code is clean and well documented (meaningful var names and formatting as well), the archetecture is relatively strightfoward, and the developer took some time to write some notes on the use of his components. In Java this would include class-level javadoc; in other languages it may include a header at the top of the source code.
Also, if the original developer is available and open to questions, it makes learning the archetecture much simpler - no puzzling out what he was thinking.
I've been on both ends. Taking over a code base and handing it off.
You should:
Identify areas that aren't completely
obvious. So, if you have a directory
called "xml" but all your flash
object get their data from
"flash/swfs/xml" you should document
that.
Identify parts of the database which
are no longer in use. If there are
tables that simply have no use
anymore.
Identify areas of concern such as
speed/performance of certain pages.
If you have some really backwards
logic on certain pages, explain why,
if it's not been commented in the
code directly.
Any third party vendors should be
identified along with their cost and
use on the site. So if you're using
a delivery network to stream your
flash videos, definitely let that be
known.
If you have pages still in the
project, but aren't being used
anymore, identify them, or simply
remove them.
If you know for a fact that your
database was poorly designed,
contains no constraints or indexes
and has no primary keys on many
tables, mention it. It will let the
new developer know they need to
optimize the database.
If you hardcoded e-mail addresses
within the code and didn't put them
in .config files, identify that as
well.
I'm sure there are more but there are things I wish were brought to my attention on a project I had taken over at one point.
If you have written your code from the start so that it is sensibly architected and fairly simple to understand, and provided adequate documentation, transitional problems should be minimal.
But training is always nice.
For anything that requires a build environment (certain compiler, 3rd-party libraries, opensource libraries, paths, etc.,), have the original developer sit down with the new developer, at the new developer's workstation, and walk through the process of making a simple change, committing to the source control, building, smoke test, etc.. Lots of times projects that are out of the mainstream may have odd procedures for testing, or they may come from an unfamiliar repository branch, may need a specific compiler version, libraries, etc.. Bugs may be tracked differently, it may require specific logins or endpoints for testing, etc.. By walking the new dev through the process, on their workstation, you'll uncover all of those issues, saving the new dev lots of frustration.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 13 years ago.
Improve this question
This is often a bit of a problem for lone developers working on a product or a service. How can they get the word out about their product?
I recently finished a project of mine and I'm struggling a bit to spread word of it.
What do you think is the best way to promote your new product/service?
Although this question isn't strictly programming related, it's a good question for programmers wanting to get their creation out and about.
You should have a short tutorial explaining what your product does and how to use it without having to install anything or fill out a single form. I'm not exactly sure what AnyHub (The OP's website) does with my files, how I would share or manage them or why you are doing it for free.
Look at Web 2.0 sensations and see how they streamline the process from hit to customer. For example Twitter has the What, Why and How buttons right there on the front page and nothing else to distract you from them. It also has motivating testimonials there too, and is themed to represent the idea.
Also, you should be trying to find a point of pain that many people have and try to ease that. Twitter knows it is getting impossible to tell your friends what you are doing via email, sms, blogs, feeds, rss and so on so takes care of it. What do you provide (other than an alternative pricing model?) Tell me on your website.
The internet (obviously).
If you're going at it alone, grassroots via Blogging, Facebook, and Twitter work.
You can also purchase google ad words, and other ad-related venues.
You can consider an open source version of your project, or joining tradegroups/ forums related to whatver problem your product addresses, and start to build a following (but please DONT spam these groups).
Mobile phone applications are really easy to promote nowdays, thanks to Apple's iPhone App Store paradigm. Now all major players (RIM, Nokia, Palm, etc) are opening their own application stores which takes away much of the promotion effort from the developer. As long as your application, game, etc is interesting it will sell by itself. Nevertheless, everything depends on the first week you launch your app and it is up on the list of the newest arrivals.
In the desktop world things are more difficult although Sun recently announced a similar promotion scheme for Java applications. More might follow, but it will depend on Sun's success or failure.
I believe (and actually hope) that centralized "selling services" will be the primary way of buying applications, games, plug-ins, services, etc in the near future. It is far too convenient to pass.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
I will start developing my next desktop application in about a month. In the past I have delivered functional software that hasn't wowed anyone, including myself, in the usability or aesthetics department.
Does anybody know of any resources or guides or even books that could showcase examples of good design in desktop software?
There seems to be a lot of resources for web apps, but such resources for desktop applications are rather slim.
I enjoyed these dot net rocks tv videos by Mark Miller on The Science of a Great User Experience really got me thinking about good ui:
http://www.dnrtv.com/default.aspx?showNum=112
http://www.dnrtv.com/default.aspx?showNum=123
Where you can really make a difference with GUI design is if you are addressing a difficult to understand concept in a GUI.
When you are doing that, creativity is critical. When dealing with complex hardware configurations (something I had to do a lot, but probably doesn't apply to you), I've had good luck going to tech manuals and tech support people and trying to completely understand the problem. Then I took the methods they used to show me (diagrams from the manuals, whiteboard drawings, etc) and tried to code them into a GUI.
Had a couple massive successes with this.
Iteration is also critical. Prototype something quickly then beg everyone you see to try it. Ask them to solve a problem, then watch where they go first and watch what they have problems with.
Address every problem and stumbling block.
Don't be afraid to throw it all away and start over, it was only prototype code.
Separate your GUI from your implementation so that you can swap out the GUI if you find a better approach.
If you want to concentrate on just one feature, have a look at ITunes' search box which filters as you type. Other software may have had this before, but this was I think the first place I encountered it.
The difference between this and classic search was an eye opener for me in terms of readability.
Auto-complete which you see in so many places is another one. I'd recommend IntelliJ IDEA for the way it took auto-completion which emacs, Visual studio etc had for ages and added autocompletion for variable names and method names in a manner which almost seemed psychic the first time you encountered it.
You can look at Thirteen23 Experiences
To make things usable, you need to make sure that you follow existing conventions for your target platform and application type.
For example, if you're developing a Windows App you'd better make sure that control-c copies, control-v pastes, control-s saves, etc. The File menu better be the leftmost item in the menu bar, and the Help menu better by the rightmost item.
If you don't follow existing conventions, users are going to get annoyed with your application very quickly.
Google for HIG. Human Interface Guidelines typically include lots of research into best-practice in user interfaces, and explain in great detail how to design each aspect of a program. Also, have a google for "user-interface hall of shame" or something like that.
In this question I mentioned GUI bloopers. Part of great design is knowing what makes bad design and why. It is actually a great book, although I don't know how much of it is available on the website.
You can check case studys on websites of GUI companys. I fund few at www.puzzlehead.com
Check there and also other sites.
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 1 year ago.
Improve this question
Granted knowledge is best retained when put into practice, but as programmers I'm sure there's just too much information. Besides annotating your books, what other methods do you use for your own personal knowledge-base so you can have an easily accessible reference?
Do you create your own wiki or use software like wikidpad, or save them as plain text, bookmarks, pdf, web pages etc..? Or do you just treat google/SO as your giant knowledge-base and search only when required?
You may find this similar
https://stackoverflow.com/questions/10961/have-you-used-a-wiki-in-your-project-or-group, and of course this question can easily relate to non programmers as well.
Blog about it. That way you'll always have it no matter where you are, and that information gets shared with others.
I use Tiddlywiki to keep all of my development notes together, other than notes or handouts that I might get at a meeting that I want to keep. Those go into a folder for the particular project and I add a reference to them in my Tiddlywiki so that they don't get lost in the shuffle. I tag everything with a limited set of tags (rather than going overboard with the tagging, I have a set of 15 tags that cover the projects and categories I need) so I can get back to them quickly.
Works for me.
Otherwise, I blog about them as needed, use drive indexing for massive searching across lots of stuff, and keep a short daily summary of activities (1 or 2 lines) for better recall.
There are several solutions that I have seen people use successfully:
blog about it (as others have noted here)
maintain a Wiki (local or hosted)
keep it in a plain text file
use Backpack
use a hosted office solution (Google docs, Zoho)
email it to yourself in Gmail (yes, really :) well, makes stuff easily search able)
I personally use a TiddlyWiki (easy to use; very good search) which I carry around in a USB pen drive and which is also checked in to my SVN repository; and a small "notebook" (created from here) which fits neatly in a wallet, to jot down things when I am not near a computer.
Start a wiki.
ScrewTurn is what I use.
I've been storing my notes in Google Documents(google.com/docs). I've tried wikis but the cost of setup and maintenance hasn't been justified yet. I may need to look further into this option as my set of notes get larger.
Another thing to consider is ye olde programmer's physical notebook. Paper and pencil should never been underestimated in this digital age.
As far as personal Wiki software goes, I've been a big fan of VoodooPad for OSX. It's a nice self contained Wiki applications. No need to maintain a web server or have your Wiki hosted anywhere but your computer. Plus you can export into a variety of formats. It's very inuitive to use and can store just about anything you want.
It should also preserve syntax coloring if you were to extract a code sample (I don't have it in front of me so I cannot confirm).
I like Treepad for organizing notes. It's based around a tree structure, and each node can contain a text document, and have child nodes.
It's not particular designed for programming, but it's very easy to use.
org-mode for Emacs. I use it for planning work (short- and long-term), TODO items, random how-to notes (with clicky links to source files and URLs) — All in one single flat file. It has unicorns!
I use codekeep to store my code snippets
Occasionaly I store a few notes on google notes too
Mostly in a plain text on a flash drive, which is in the key ring along with keys from home. Plus eventually backups on the web site. This makes it available on any platform and in any place, wherever I go. There's still places without internet access you know.
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
Back in the days of Unix, you couldn't even close a software without reading the man page first. Then came Mac and Windows with consistent menu layout and keyboard shortcuts, but you still saw paper user manuals shipped in the shrinkwrap box, which described each and every single operation possible in the app. After the Internet, help files became html documents.
Nowadays with Web 2.0 applications, you hardly see the Help. Even if it's there, they simply describe some specific tasks. In other words, the apps are relying more on the common sense or don't-make-me-think factor of the user base.
Years ago Microsoft came up with a concept called Inductive User Interface, which basically tells programmers to put in instructions on the apps itself, but I am not sure how popular that idea is.
Are help files, user manuals, and context sensitive online help with F1 key dead? Have I failed if user could not find out what to do from the UI? If not, what degree of help should I provide? (both for desktop and web app)
EDIT: How does documentation/help file mesh with agile development methods? For example, should the developers think twice before UI changes that may obsolete a bunch of screenshots?
Three notes on help:
F1 / stand-alone context-sensitive help was always doomed. It was hidden by default, and so the people who most needed it were least likely to read it. There was hope at one time that we would be able to train users to always hit F1 when they ran into trouble, but too many applications without useful context-sensitive help... combined with too many bizarre help interfaces... pretty much killed this.
Manuals are as important now as they ever were. Not so many printed manuals anymore, but online manuals are better than ever. The proliferation of wiki-as-a-manual systems has helped here, reducing the up-front cost of creating good online documentation. Of course, plenty of people just don't read...
The beauty of using web pages as an application interface is that you can combine useful context-sensitive help with the UI, removing the barrier for novices and others who otherwise couldn't be bothered to look for relevant information when they get stuck.
Of course, there are still plenty of apps, even online apps, designed with obtuse interfaces and a tiny little help icon in a corner somewhere, presumably hoping that the latter mitigates the former. Pity them.
No way. You look at the amount of documentation and training and marketing expenditure even MS puts up.. you'll get your answer.
Try using someone else's product, and you will learn the true value of documentation - I'm learning Godiagrams right now.. :)
So I can say without a doubt.. NO and it never will.. no matter how intuitive user interfaces get.. beyond a certain size, you will need help and training. But by understanding the user and what he needs to get done, you could design it such that the time he/she needs to learn the system to do his/her routine tasks is minimal.
Have I failed if user could not find out what to do from the UI?
If not, what degree of help should I provide? (both for desktop and web app)
They should be able to use your your app to do basic things from the UI. eg say for an image editor, they should be able to create a new image, and draw some lines then save it just by looking at the UI.
This is best done by following common layouts (like having new, open and save under file in the menubar, and using the standard open and save dialogs).
The same goes for webapps, people exspect to be able to do the basic stuff without having to read the docs, but for more advanced features people will still read the docs. (eg most pople will read the docs for say BB code, or markdown at least sometimes, but they expect to be able to post without having to know them)
Are help files, user manuals, and context sensitive online help with F1 key dead?
They still have their place. People will use them to learn about how to best use various features, for example markdown or bbcode, or how to use filters to get certain effects in an image editor.
I've been incorporating context-sensitive screencasts into my applications. I've found this helps non-technical users grasp the application quickly, without asking for live help.
The Idiot/Dummy books must be doing quite well. Imagine if the standard application help was as good as those books. The standard F1 help for a lot of apps is just awful.
Is help dead? No, but some of it should be taken out and shot.