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 8 years ago.
Improve this question
I had recently stabilised developments of a major open source library written in Java. I have then published an article on the server side, which has brought me a lot of positive (but also critic, constructive) feedback. And a first contributor, which is great!
See the article here: http://www.theserverside.com/discussions/thread.tss?thread_id=61162
And the library: http://jooq.sourceforge.net
So with all of that good feedback, I have a great feeling about my project, in a way that I am creating something useful and original. Some key ideas behind my project, and why I think it is original:
It's an or-mapper. OK, now that really isn't original... ;-)
It has code generation in it. OK, still not original. But that's always nice.
It allows for creating type-safe queries in Java using its own domain specific language. That's better. No string concatenation. JPA has only just recently copied criteria queries from Hibernate.
It allows for doing so with all SQL features, including complex joins, nested selects, unions, aliasing, etc. Now that seems original to me. OR-mappers tend to try to ignore the relational data model behind RDBMS.
It supports all kinds of native non-standard functionality like UDTs, stored procedures, native functions, etc. I don't know any or-mapper that does that.
I think that these key ideas are useful for a very specific type of developer. That specific developer
interfaces Java with huge legacy databases.
knows SQL well and wants to use it extensively.
doesn't want to learn any new language (HQL, JPQL, etc)
doesn't want to spend one minute fine-tuning some sophisticated XML-configuration.
wants little abstraction over SQL, because his software is tightly coupled with his database. Something that I think the guys at Hibernate or JPA seem to have ignored.
EDIT: needs a strong but light-weight library for database access. For instance when they develop for mobile devices (see comment by SRM).
Now is the beginning of the hard work. How to get attention? How can I attain a bigger crowd? How can my project become relevant? How to reach to that "specific type of developer"?
I would say set up a professional looking site (one that doesn't look like it was designed by a 15 year old script kiddie). Make sure you have ample documentation with plenty of help and/or tutorials for using your library. Example applications are also good to see a real world usage of the library.
Once you have that setup I would do some typical SEO to drive traffic to your site. This includes blog articles, links back to your page and or articles, and possibly buying some Addwords from google.
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 5 years ago.
Improve this question
I need to document a MS-Access application that was created, developed and maintained completely by a power-user over 10 years.
This is an interesting situation because what they want is a manual so that a future developer can come in without prior domain knowledge and make changes to the frontend or the backend in a timely manner.
There are a few questions on my mind for this little project:
What is a good manual design creating application? Microsoft Word doesn't quite cut it.
What kind of things would you, the developer, need to know in order to make changes to things like forms, reports, tables or other Access objects?
Anything else I missed? Any pitfalls?
You could start with generating some automatic code documentation using MZ-Tools add-in for VBA. The same add-in can help you clean unused variable declarations, generate line numbers, reorder procedures within a module, etc.
Documenting forms is more difficult. My proposal would be to keep a screen shot, alltogether with a .txt file obtained through the undocumented application.saveAstext method.
In my experience, Access and VB6- based programs are plagued by more code replication and technical debt than programs in mainstream languages. I'm not sure why. Maybe it's the nature of Access as a "prototype" or "toy" database (though it can be quite powerful when yielded correctly).
If I had to choose between expending time on documentation and expending time on reducing technical debt, for example by remodularizing, eliminating repeated code, splitting long functions, etc., I would choose the latter. The improvement to maintainability and readability would be greater.
I know this is closed for long, but I can't refrain adding my 2 cents:
In the case mentionned, I think the most usefull doc to produce is a FUNCTIONAL documentation (which should have existed before starting the development in an ideal world).
Second is within the code itself, and that includes the VBA but also the field descriptions which can be set in Access and SQL Server.
Third is a (or a set of) nice database diagram.
Once you have that, all the rest can be generated by the new developer using HIS favorite tools.
Speaking about tools, I particularly like and recommend:
MZ Tools: specially to easily find which routines call the one your looking at
Smart Indent: to properly indent code. Trying to read badly indented code makes me sick
SqlSpec: (not free) generates HTML doc of the database itself for most database engines
Have you tried the using the built in database documenter? It will print out all tables, indexes, forms, controls, each property of controls. Code, the sql used and just about any thing else. This results in huge, but just massive printouts. However, while it will kill a few trees in the process it sure is a great way to impress the boss.
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 7 years ago.
Improve this question
I have already built a site from scratch. It has banning, PM, comments, etc. The PMs and comments are done using markdown (like SO).
There are pros and cons for writing my own or using another software. But some cons keeping me from using another forum software is
Multiple Logins: One for the site, one for separate forums.
Need to Customization code: I'll need to change the toolbar in the forum software so I can access pages on the regular site.
Look consistency: It may look drastically different from my site even after applying lots of css changes.
Banning and User consistency. Users may be ban on site or on forums but not the other. users may select a different or multiple usernames on the forum instead of being forced to use the same username on both site and forum.
Should I write my own forum code or should I use something already written? What are some reasons for or against writing my own and using forum software?
The heuristic I tend to use is that if at least two or three of these are true, it's probably worth writing yourself:
It's one of your core business offerings.
You have the time, money and resource to specify, design, build, test and support it.
The amount of time you would need to spend evaluating, prototyping with, integrating and customising off-the-shelf packages is near to or greater than the amount of time you estimate that it would take you to build your own.
The off-the-shelf packages do not have good support. By 'good support' I mean that you can raise an issue, and be assured that somebody will look into your specific issue and provide a fix if it is found to be a bug.
None of the off-the-shelf packages meet your quality bar for security, performance, quality, etc.
You are not writing open-source software, and the off-the-shelf packages have a viral open-source license; be particularly wary of AGPL and other similar licenses.
One of the oft-quoted articles about this is from Joel Spolsky. Lately he seems to have just been writing flame-bait, but this was one of his worthwhile early posts.
Note that you can also take a combination approach, and use some pre-built things such as recaptcha and gravatar even from within a bespoke solution.
Writing your own forum software is nowadays in almost no case useful. The available software is highly customizable. For example, you can create your own skin to fit with the layout of your website. You can integrate the login with that of your website.
Writing your own forum is so complicated that the quality of your own software will be much lower than of something like phpBB or vBulletin. And dont forget the security bugs, the mentioned software has been reviewed by a huge amount of people. Until you reach the same quality (functionality, stability, security, etc), your website will be outdated and your forum software with it.
Once again, the current forum software is so adaptable and extensible, that it doesnt make sense to make your own.
I think it highly depends on your needs for the forum.
First off, is the forum itself an essential part of your website's function? Or is it more of a 'support' style forum?
If it's essential to your daily business, then it makes more sense to write your own - or at least highly customize an existing package.
If what you need instead, however, is a vehicle for customer support, or some sort of generic community revolving around your site, I might recommend looking at a completely different vehicle: something like http://getsatisfaction.com, or a Google Group, or some such.
(I'm in no way affiliated with either of those sites).
Regardless of the solution you choose, I'd recommend you give some serious thought to how essential the forum is. If it's not, then I wouldn't waste too much time configuring/setting one up. Instead, focus on what your site's main draw is, and spend the bulk of your time on improving that. You and your userbase will be much happier with that, IMO.
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 9 years ago.
Improve this question
I've always worked in small companies, mostly doing small websites, and they all sucked in project management.
That means I have no experience whatsoever (even though I learned a little bit studying on my own) about the best practices and tools when developing a project.
Currently I'm unemployed to finish college and I decided to take a small PHP project mostly to learn both the language and project management.
It's just an idea I had for a website, I don't need to get money from it and it is not big, so I'm not concerned with deadlines or business plan, or a main goal. The main goal is to learn the technical stuff.
The only thing I'm caring about is doing it right, you know, the best practices in PHP, server setup, security, the tools for the job.
I'm not asking for a complete rundown on any points, just things like
Remember to always sanitize user input
Use this tool to manage version
Remember to set this apache option
Here's a good link on how to organize your files
Things like these will be already of great help!
Thanks
Non language specific:
Devise an error handling strategy early. What will you do when error conditions occur, will you log errors, how? where? What information will you log? Will you throw exceptions, return error codes?
Assume that your website is succesful, people start using it, then it breaks how quickly can you figure out what went wrong? Consider your whole error strategy from that perspective, not just from what happens while you developing and you're in control.
Some things that helped me a lot (in no particular order)
Version control (SVN in my case)
issue-tracker/wiki (e.g. Trac)
if you are writing markup: some kind of tidy
... and a validator
if you are writing code: a lint tool for your specific language
TODO-list app (for small TODOs)
a cheap VPS host to test things (I also use mine to host SVN and Trac)
There's a good question already answered about bug tracking and version control for single developers.
As for PHP style, I usually like to follow the Zend Framework guidelines. For deployment advice, you might want to head over to ServerFault.
Here's some answers to the project management / best practices side of your question:
https://stackoverflow.com/questions/601759/what-professional-standards-do-you-maintain-in-a-side-pet-project
Start off by choosing a framework you're comfortable with. I would recommend Code Igniter, CakePHP or Zend Framework. It will help(force) you with a basic organization of your code and files. All these frameworks has dedicated forums with passionate developers.
From the project management angle I would recommend you to set goals and milestones. It will help you get things done even though you're learning. Set target of that you should accomplish for this month, this week and today. Small and easy targets like "create signup form" or "set homepage set". It feel so good checking those off. There is a lot of tools to use for this, like Backpack or Basecamp (free versions) or Things (mac application).
Be sure to use PHP5 and not copy ugly PHP4 code.
For project management software, check out DotProject (http://www.dotproject.net/).
About PMS (Project Management Software), you can take a look at
[http://www.axosoft.com][1].
This compagny edits OnTime, a very nice PMS.
Moreover, this software is TOTALLY free for a single user !
This software provides full support of SCRUM development method, for me one of the best !
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 4 years ago.
Improve this question
After every new program written a lot of paper documentation remains.
Apart from the usual scribble notes from the programmers there usually is a nice heap of papers containing physical model explanations, calculations and so on (equations, tables, graphs, little pictures describing variables ...)
We usually do numerically intensive calculations in console applications, which are not released to the public (remain in the house, only results go out). Before each project is finished all those papers have to be packed somehow with the application, so that one day, when someone will be reusing parts of it, has some idea what is what in there.
So far, we've been using the 'dirty' solution of just scanning all of it, and packing it up on the disc with the application.
So I was wondering ... for all science guys here in a similar situation ... how do you handle project documentation which is needed, but not released to the public ?
(the one that does, goes to the dtp laddies, and they make it nice and shiny - not our problem anymore :)
I use one of three options:
Keep everything in my lab notebooks, which I archive myself, for low-level stuff
Scan the paper document, and add to source control in pdf. It's ugly, but if someone needs it, it's there
Transcribe the equations, results, etc... in a clean format (usually Latex) for future reference, and again, add to source control. Official paper copy gets signed (I work in a highly regulated domain) and filed in a binder.
In the projects I've worked on we have done a lot of physics calculations in our programs and consequently we have a lot of whiteboard sessions with equations we are working on.
We keep a wiki for each major project and after each whiteboard session we physically photograph the whiteboard with a digital camera and upload/organize it within the wiki. We also scan in paper documents from developers notebooks if it is important and include it in the wiki as well.
Then, we back up the wiki on disc for storage. So our solution is pretty similar to yours, other than we use the project wiki for organization.
If it's important, it seems to me you should treat the internal documentation with the same care with which you treat the public docs.
I create UI paper prototypes when designing the UI of an application, which produces lots of A3-sized papers (in one project we had many desks covered with papers). When the design is ready or it needs to be mailed to somebody, I take pictures of it with a digital camera, so that I can produce a series of pictures showing how to perform some tasks on the UI, which serves as documentation of how the application is meant to work. This serves also as a backup, in case somebody steals/cleans away the original papers.
Here is some of the thoughts... Not so practical though :)
We can make it part of our Check-in notes. This may help the developers going to maintain the application.
Update the requirement document/Low level design document with these items
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 7 years ago.
Improve this question
Design patterns are great in that they distill a potentially complex technique into something idiomatic. Often just the fact that it has a name helps communication and understanding.
The downside is that it makes it easier to try to use them as a silver bullet, applying them to every situation without thinking about the motivation behind them, and taking a second to consider whether a given pattern is really appropriate for the situation.
Unlike this question, I'm not looking for design patterns that are often misused, but I'd love to see some examples of really solid design patterns put to bad use. I'm looking for cases where someone "missed the point" and either applied the wrong pattern, or even implemented it badly.
The point of this is that I'd like to be able to highlight that design patterns aren't an excuse to disable critical analysis. Also, I want to emphasise the need to understand not just what the patterns are, but why they are often a good approach.
I have an application that I maintain that uses a provider pattern for just about everything -- with little need. Multiple levels of inheritance as well. As an example, there's a data provider interface that is implemented by an abstract BaseDataProvider, that is in turn extended by a SqlDataProvider. In each of the hierarchies, there is only one concrete implementation of each type. Apparently the developer got ahold of a Microsoft document on implementing Enterprise Architecture and, because lots of people use this application, decided it needed all the flexibility to support multiple databases, multiple enterprise directories, and multiple calendering systems even though we only use MS SQL Server, Active Directory, and Exchange.
To top it all off, configuration items like credentials, urls, and paths are hard-coded all over the place AND override the data that is passed in via parameters to the more abstract classes. Changing this application is a lot like pulling on a thread in a sweater. The more you pull the more things get unraveled and you end up making changes all over the code to do something that should have been simple.
I'm slowly rewriting it -- partly because the code is awful and partly because it's really three applications rolled up into one, one of which isn't really even needed.
Well, to share a bit of experiance. In C#, I had a nicely cool design which used lots of pattern.. I really used lot of them so to make the story short, I won't name it all. But, when I actually tested with real data, the 10^6 objects didn't "run smoothly" with my beautiful design. And by profiling it, I just saw that all those indirection level of nicely polymorphisms classes, proxy, etc. were just too much.. so I guess I could have rewritten it using better pattern to make it more efficient but I had no time, so I practically hacked it procedurally and until now, well, it works way better.. sigh, sad story.
I have seen an asp.net app where the (then junior, now quite capable) developer had managed to effectively make his codebehinds singletons thinking each page was unique which worked brilliantly on his local machine right up to the point where the testers were fighting for control of the login screen.
Purely a misunderstanding of the scope of "unique" and a mind eager to use these design pattern thingies.