As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I want to program with a friend (or a couple) out of the same dropbox folder for a project. I want to put all the assets in the same folder, including config and db files. What I really want to know, is why this might be a bad idea.
I can already think of a bunch of positives:
Quickly sync work. As in, almost instant sync. Dropbox, I've noticed, really is that fast that it is almost like working local.
Program multiple parts at the same time
Dropbox is fast enough to allow one person to add a method, and then another person ad theirs a moment after
Eclipse or Gedit both check for changes in the files so we won't accidentally end up with a conflict.
This isn't a substitute for proper source control and versioning, which we would still use Git for. Dropbox does have 30-day versioning, but for obvious reasons, it is no substitute.
I think this is especially powerful in the beginning when this are changing so fast that every team member having the exact same copy of everything is very important. This is a Rails apps if that matters.
Don't use Dropbox for that, because you'll be on the phone/IM/whatever trying to figure out who is going to edit a particular file (no concurrency AND no checking out!). Use a concurrent versioning system like GIT or Mercurial. There are tons of other advantages. On the downside for Dropbox, you will end up with "conflicted files" all around, which you won't know what to do with much.
The other advantages to a real version control system are well-known. Here's a list from some random blog:
File space.
Let’s say your code
changes 10% each week. Under the
“folder backup” method, each week
you’re saving 100% of the code. Using
a proper VCS, you’re only saving 10%
of your code. I know hard drive space
is cheap, but it’s not free and I
never seem to have enough.
History.
The key to VCS, in my opinion, is
being able to document your changes in
more granular level than a file called
“Changelog.txt” that might not get
changed whenever you work on your
code.
Bug-location:
Let’s say you find
a bug in a method. You search the
history for that file and let the VCS
runs the diffs for you.
Complete
freedom to change code.
You don’t have
to worry about breaking something, or
removing possibly useful code. Before
I moved to VCS, I used to comment out
old code liberally but keep it ‘cos I
might need it. This quickly becomes a
PITA.
If you use git, there are several providers for free or cheap online repo.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
This somewhat applies to all cloud storage, but specifically I'm wondering:
Is it practical to use Google Drive as a root development folder?
For example with setup like this:
C:\Google Drive
\Projects\...
\Photos\...
\Docs\...
would I even need to have local copies or is this type of service stable enough to just use as a "workspace"
My concerns would be if I use an IDE or have many things over at once, will it causes noticeable latency or bandwidth problems while I manipulate files?
If this is not practical, is there a "best practice" for this type of infrastructure now that cloud storage is being so widely used?
Note that I'm interested in the answer from a programmer's point of view
This was my first thought when Google released Drive. I've been running eclipse using a Google Drive folder as the workspace for a few days now. I do mostly JavaScript and PHP.
The beauty of Google Drive is that it does all the work behind the scenes. I've manipulated folders, imported projects, deleted folders and there is no issue client side. It makes no difference whatsoever to eclipse. It just takes a minute or so and the changes are reflected on Google Drive.
That being said I can save a single file as I work and there is no noticeable lag between save and sync. I can't physically see it anyways. I also agree that revision control should be combined with this as Google Drive's revision system is a bit limited, it only works for Docs formats.
Save often and let your computer sync for a few minutes at the end of the day and you should have no trouble using Google Drive as your workspace. The System Tray Icon tells you sync progress so it's easy to see when it's done.
Yes, you can safely put your workspace folder in Google Drive and as a bonus you will be able to make quick edits using an online IDE, e.g. ShiftEdit, Drive Notepad or Neutron Drive.
This would work, but your probably best bet is revision control. You could of course combine both to have a revisioned directory on your Google Drive, which would be quite cool.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
The company I work for has an internally developed Word2003/VBA application that's already about 6.5 mb in size and they're looking to add an additional 200+ macros to it, which, I'm assuming, will make it much larger. This seems to me to be a terrible idea, but finding resources to redevelop the tool with VSTO or some other more useful technology will be a challenge.
So here are my questions:
Is it okay, in a pinch, to have a
business dependency on a Word
template with macros that's 10, 20,
or 30 mb?
Is there a Microsoft-defined or
suggested limit (file size, number of
macros, level of complexity) to how
far you can/should extend a VBA app
before it becomes unusable?
In essence, I'd like to know if there is a compelling technical reason to bite the bullet and redevelop this app.
This will give you the limits of Word 2003/VBA: Operating parameter limitations and specifications in Word. Given the limit is 150 macros, it doesn't look like they will be able to continue to use this to add 200+ macros.
I would look at moving some of those macros to an Add-in. Still VBA, but can be used on multiple files and gets the code away from the data (which is a programming win, generally).
--Edit--
As for scaling and size... I think it's all in the design. If it is thrown together, performance will suffer. The file can handle the overall size, but there are limits to Module size (64k), and procedure size (not well documented, but the IDE will let you know when you've hit it). If you start to approach 30mb of text only then you're going to want to find another solution.
You haven't mentioned security, but since this has to do with medical information it should be said that VBA is not secure. If the code is proprietary, and being offered to outside sources you might want to wrap it up in an .xll and install as an add-in. This might actually offer a faster runtime as well.
I know this is an old question. But its seems unlikely there were 200+ macros. Unless they've made every function, or sub a seperate macro, instead of putting them all in the one Macro.
You can write a VBA application within a word macro. But this doesn't sound like it was. Its just a a bunch of macros.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
What are release notes for and who reads them? Should/could they be automated by just spitting out bug fixes for the current release, or do they warrant careful human editing?
So, anybody with a link to best practices(reasoning behind) in regards to software release notes?
Bugfixes and added features. Users will read them to determine if they should go to the trouble of installing an incremental upgrade, or wait until the next release because this one doesn't add any features they need or fix any bugs in features that they were using.
I'd say they at least require a human to read through them and make sure that each note is useful. It depends how good the comments on your bug fixes are.
Release notes are also important to your testing organization (if you have one), so that they know what's changed in the release and needs testing.
This really depends on who your application is built for and your organizations goals. However, I tend to believe that release notes need to be a concise listing of important key additions, enhancements, or fixes that are included in the particular release.
Sometimes a simple dump of the bug tracking system information is enough, other times, I find that they need to be refined.
The key is that typically Release Notes are believed to be the "Hey look at what we did" type listing of changes.
Our release notes are human created instead of machine created. The cover three main topics.
What is included in the releases
(list of files)
How to install it
What changed since the last version
(especially if the changes are not in
the manual yet).
items 1 and 2 don't chnage much from version to version, but they need to be reviewed. Item 3 takes the most work.
Release notes are also very important in production environment.
They help answering the age-old question:
What the heck is currently running into production ?
Or the more refined question: does this bug has actually been fixed in this release ?
I habitually read release notes. I tend to want a full comprehensive list of feature changes ( or as good as plausible ) in order to greater empower my utilization of the new product.
I want to see when certain critical bugs, or critical security issues are solved.
Release notes and READMEs can be really important if your customer has to take special action in addition to normal procedures in order to upgrade. It also be useful to warn customers/users of any db upgrades that can automatically happen as a result of installing a newer patch. The way I see it, Release Notes and READMEs should be written for the System Administrator audience. So include the kinds of things they would want to know about: summaries of important changes, how to install, known bugs, anything your software might do that would make someone pull their hair out, etc.
Release note depend of your organization.
I can talk for my organization. We use release note in PDF format and every time we publish a clickonce or a backend version. We send to office manager the Release note. This is a document used by the top administrator of the business (not only IT). This document is a way for them to know what is going on. What have changed, new features that are now in production, bugs fixed, and other thing that they might want to explain to their user.
This is a document that can be between 3 to 4 pages, describing the job that has been done in this version with brief words.
This is of course highly dependent on the type of application/service/whatnot,
but I've found that reading the release notes of my favorite developing tools etc..
often make me stumble upon nice, interesting or even killer features that I'd probably miss if I did'nt at least skim the notes.....well, perhaps not killer, but you get my drift ;-)
As most computer power users(now what kind of expression is that...)
I never bother much with ordinary documentation, so this gives me
that little something extra something besides clicking, hovering and faq'ing...
Release notes are for testers and users to know what's new/changed. Additionally, release notes can be used as supporting documentation when billing a new "version" of a software for client that you are building for them. v1.31 seems a lot easier to relate and drill into.
Rather than compile both lists manually, if you can use your release notes to do that for you it's great.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
As best-behaved as I try to be about keeping my unit tests disconnected from the database, etc. etc, it still seems inevitable that my day will be interrupted by small regular enforced breaks while I wait for my machine to do something boring.
I personally find swordfighting makes me lose my train of thought. I'm often 'in the zone' when I run a build or suite of tests, and I'd prefer something that keeps me in the same focussed frame of mind, jumping me right back to hacking as soon as the build / test run / migration is done.
I used to fantasize about a Tetris plugin for Visual Studio that popped up during the build and then paused and disappeared automatically when the build completed, but I never actually did anything about it. Lately we were thinking about building something into autotest which helps you learn Spanish while you wait for the tests to run, or maybe feeds you relevant stack overflow questions to answer.
So. Suggestions please. Points for fun yet rewarding activities.
StackOverflow
Coffee
StackOverflow
Side project coding
See also How to keep concentrated and focused while waiting for your compiler?
I normally use this time to read blogs ant to check the bug list, to see if there is something pending that I forgot to do.
Ideally?
Write up notes on the fixes/feature added. (Notebooks are GREAT when two years from now you need to decipher something you did.)
Read something that pertains to your work.
Check for other small errata and bugs.
Document (for other people) your feature/code.
Realisticly:
Stackoverflow
Slashdot
Lifehacker
Blogs
Use the time for ordering a new, much faster developer machine / server.
Coffee, Chitchat, StackOverflow.
I usually read blogs, articles, mostly work related.
I have dedicated time to read everything not work related (30 minutes time-frame after lunch).
I also find myself going through our websites to see if I find a bug or something that can be improved.
And on a Friday (like today:) ) I read Freak Angels:) Warren Ellis on-line free comic. The man is on a rampage on that one:) Check it out:http://www.freakangels.com/?p=23
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
An obvious answer is "an internal wiki". What are the pros and cons of a wiki used for software documentation? Any other suggestions? What are you using for your software documentation?
Loren Segal - Unfortunately we don't have support for any doc tool to compile information from the source code comments but I agree it would be the best way to store technical documentation. My question was about every kind of documentation tho - from sysadmin type to user documentation.
That's a very open ended question, and depends on many factors.
Generally speaking, if you use a language that has good documentation generation tools (javadoc, doxygen, MS's C# stuff), you should write your documentation above your methods and have your tools generate the pages. The advantage is that you keep the source of your text alongside your code which means it is orgnanized in the logically correct place and easily editable when you make a change to the behaviour of the method.
If you don't have good doc tool support or don't have access to source code, wiki's aren't a bad idea, but they're a second choice to the above.
Note: I'm talking only about code documentation here. Other artifacts obviously cannot be stored alongside code-- a wiki is a great place to put those documents. Alternatively if you use some CMS you can simply commit them in some docs/ folder as text/pdf/whatever files to be editable via the repository. The advantage there is that they stay with the repository if it is moved whereas a wiki does not (necessarily).
Tools are important, but don't get too bogged down in finding the magic tool. No tool I've found yet has a "document everything magically using tiny invisible elves" tickbox. :-)
A wiki will work fine. Or Sharepoint. Or Google docs. Or you could use a SVN repository. Hell you could do it with pens, notepaper, and a file cabinets if you really really had to. (I really don't recommend that!)
The big important key is you need to have buy-in throughout the organization. What happens in a lot of shops is they go and spend a bunch of time and money on some fancy solution like Sharepoint, and then everyone uses it religiously for about two weeks, and then people get busy with hitting the latest milestone and that's the last anyone hears about it.
Depending on your organization, field, the type of products your developing, etc., there are a few solutions to that, but one way or another you need to set up a system and use it. Appoint someone the official documentation czar, give them a cluebat, and tell them to hit people in the head everytime they say "oh yeah, I'll finish documenting that next week...". if that's what it takes. :-)
As for tools... I'd recommend Confluence by Atlassian. It's a fine wiki, it's designed to work in an enterprise environment, it has a lot of nifty features, it's customizable, it integrates well with some of the Atlassian's other nifty tools, and is basically a pretty solid product.
«Software documentation» is a very general term. There is «End User documentation», «Developer documentation», «QA Documentation». First one is usually developed by qualified techwriters. Other ones may be dynamically formed from wikis, documentation comments from source code etc. All this stuff maintenance process usually is very complex and each software company follow its own way. But there is one necessary point for all these ways: each code commiter, architect, manager, qa engineer MUST store well arranged each piece of information which may be helpful for the others. And someone else MUST keep an eye on this pieces storage and rearrange pieces if required. All this steps greatly improve all activities related to development process.
Assuming you are talking about code documentation versus user documentation, an internal wiki is great if you do not need to distribute the documentation for the code outside of your organization, to contractors or partners.
Javadoc or DOxygen is more suitable if you want distributable code documentation.
If you are referring to user documentation, you may want to have a look at DITA.
I started experimenting with a way to do user documentation with these goals:
Markdown/Html/Javascript/file-based relatively linked documents for portability (can run on local file system or you can throw it on a webserver), built-in handling of screenshots (interactively resize), and open source in case anyone else may want to do something with the crazy thing.
Your document source is written in Markdown and rendered to Html via Javascript at browser runtime.
Mandown - http://wittman.org/mandown/
We currently use inline documentation parsed by an external application (PHP + PhpDocumenter) plus various internal wikis. At times it's painful at best (mainly because only one person update the wikis or the docs...)
However, I've been looking at using ikiwiki to do internal docs. It integrate with your source countrol system (including Git, Subversion, Mercurial, Bazaar, TLA and Monotone) so all your docs track with your project. It is built in Perl and has an extensive plugin system (including multiple markup languages, with the default being Markdown). Also, the source control system is plugin based, so if what you use isn't immediately supported you could add your own. In your preferred language, if need be, since it supports non-perl plugins, too.
My company uses a variety of Sharepoint and a wiki. Sharepoint for specific documents like requirements, presentations, contracts, etc, while the wiki is used as a help guide a developer repository for tutorials on using internally developed libraries.
Yeah, we use a wiki, we also use Google documents. I find that Google documents is better than most wikis I've tried and, if you don't need to track all changes, you lose nothing. Google docs provides a good collaboration framework.