Here's some tips some loosely based on agile methods, which should be pretty good for one man teams, as they don't have much overhead compared to usefulness.
Make a deployment script - a single command you can run to deploy the app. This way you can easily repeat the steps you do to deploy the app. This reduces chances of making a small mistake or forgetting a step when deploying to production or staging
I've found developing on my own PC is usually fastest for me. No network delays when working, familiarity with the OS and tools. In the end what matters is personal preference.
It would be a good idea to have a staging environment, preferably on same hardware/software as the final production environment. This will allow you to confirm everything works OK there, and can allow clients to test drive the changes.
Try doing periodical releases, similar to Scrum sprints. Choose what features you want to complete for the next release. This makes it easier to concentrate on the most important features as you know what you need to do, and also makes it easier to display progress (Ok this release features A, B and C). Only choose new features for the current release if you finish the ones you chose. Tag each release in source control.
For the above, you may wish to use Trac to keep track of features, as you said. What tool or approach you use doesn't matter, as long as you have some kind of map or document about what you're doing.
If you are familiar with unit testing, you may want to consider using Test Driven Development. If not, it might be a good idea to start learning about unit tests
And last but not least, make a schedule and stick to it. Otherwise your project may end up taking considerably longer than expected.
I hope at least some of these help you avoid some mistakes I've made earlier in my career =)
If you can change it without too much cost, double or quadruple the RAM. I have a 256 MB (fixed) "workbench" VPS and have had trouble running Trac/Python, Apache2, one or two PHP applications, and a remote desktop connection at the same time (the box would just refuse to do anything and claim "out of memory"). This was a Windows Server 2003 VPS, Linux is probably a little more frugal overall but more RAM won't hurt.
As for the planning, I'm not sure whether Trac tickets are the way to go for the first steps and basic development. They're great for handling single issues, ideas and features but for the big picture (functional requirements, drafts on what is going to be solved how, feature lists), you may be better of with just an office document, UML diagrams, or whatever you use to collect ideas and build a structure with.
发布评论
评论（2）
这里有一些松散地基于敏捷方法的技巧，这对于单人团队来说应该非常好，因为与有用性相比，它们没有太多开销。
最后但并非最不重要的一点是，制定时间表并坚持下去。否则，您的项目最终可能会比预期花费更长的时间。
我希望其中至少有一些可以帮助您避免我在职业生涯早期犯过的一些错误 =)
Here's some tips some loosely based on agile methods, which should be pretty good for one man teams, as they don't have much overhead compared to usefulness.
And last but not least, make a schedule and stick to it. Otherwise your project may end up taking considerably longer than expected.
I hope at least some of these help you avoid some mistakes I've made earlier in my career =)
如果您可以在不花费太多成本的情况下进行更改，请将 RAM 加倍或四倍。我有一个 256 MB（固定）“工作台”VPS，并且在同时运行 Trac/Python、Apache2、一两个 PHP 应用程序和远程桌面连接时遇到问题（该盒子会拒绝执行任何操作并声称“内存不足”）。这是一个 Windows Server 2003 VPS，Linux 总体上可能更节省一些，但更多的 RAM 不会有坏处。
至于规划，我不确定 Trac 门票是否是第一步和基本开发的出路。它们非常适合处理单个问题、想法和功能，但对于全局（功能需求、将如何解决问题的草案、功能列表），您可能最好只使用 Office 文档、UML 图或无论你用来收集想法和构建结构的东西。
If you can change it without too much cost, double or quadruple the RAM. I have a 256 MB (fixed) "workbench" VPS and have had trouble running Trac/Python, Apache2, one or two PHP applications, and a remote desktop connection at the same time (the box would just refuse to do anything and claim "out of memory"). This was a Windows Server 2003 VPS, Linux is probably a little more frugal overall but more RAM won't hurt.
As for the planning, I'm not sure whether Trac tickets are the way to go for the first steps and basic development. They're great for handling single issues, ideas and features but for the big picture (functional requirements, drafts on what is going to be solved how, feature lists), you may be better of with just an office document, UML diagrams, or whatever you use to collect ideas and build a structure with.