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
If your goal were to botch a legacy application modernization project, how would you set about it?
What are the worst strategies and practices to adopt?
Port it to node.js and bury it deep in dependencies on single-maintainer abandoned packages, many layers deep and interconnected, so that it'll be essentially a total re-write to get rid of those dependencies 2-3 years down the road when some update to some tiny package somewhere at the end of a long dependency chain breaks everything and introduces impossible version requirements (aka package A wants the new version of package X, but package B is locked to the old version, while package C is fine with the old and newer versions, but not the newest. It has announced to drop compatability with the old version in the next update...)
There's a few other languages where that would probably work as well.
The strategy behind that is to use fragmentation as a weapon against the poor sod who'll have to maintain and update that monster. If you make the dependency graph silly enough, sooner or later something will break in terrible ways.
Another aspect of bad practice is when people are mixing their front-end project with both .scss, .css, .ts and .js because they sometimes just don't find a solution of some case in TypeScript they implement JavaScript files in the same project. Then there are many cases where people implement poor JavaScript libraries in TypeScript projects that do not support TypeScript and will break the application now or later.
Some other bad practice is to not organize your .js files and write more and more code in a single .js file that will reach 1000 rows then 2000 rows etc.. and after a while, there is no point updating anything in that file because its impossible to get the whole picture.
Related
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 8 years ago.
Improve this question
I 've heard some people refering to data files(by data files i dont mean excecutables,libraries,documentations,conf files but simple text files,audio files,documents etc) as software. I have found some definitions that say that whatever is not hardware is software, although most of them clearly define software as programs,scripts etc. Is it a matter of context and opinion or is there a clear definition.
It may sound like a stupid question and it propably is, but i always when referring to software mean programs and not data files so i want to know if i am wrong.
I believe data files would be considered assets or resources, not software by itself, but stuff that the software uses to accomplish its purpose. For example, most of a game's content is assets, such as music, models, textures, cutscenes and that kind of stuff; the actual software is just the game engine and that's it.
That said, I'm not sure if this distinction could apply for legal purposes. I would believe that data files (game assets in my example) could be considered as separate from the software and this is why it is possible to do stuff like OpenTTD, which is a GNU freeware reimplementation of Transport Tycoon Deluxe's game engine originally designed to use its assets, which used to be provided by the player (until someone designed GPL-licensed assets), or like pytouhou which is Touhou Koumakyou's game engine reimplemented in Python but using ZUN's official game assets.
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 browsed some of their sites. They always point to bug list as start of participating project.But, as a newbie in that project? How can I fix bug at the beginning?
Can anybody give me some suggestions about this?
Issac Truett's answer is good.
My only suggestion would be to pick a project and download their source code. Most open source projects use CVS, Subversion, or Git to manage the source code.
Pick an integrated development environment (IDE) that supports the language of the project and attach the IDE to their source code manager.
Spend some time getting familiar with the source code, and the bug list will make more sense.
Almost every Open Source project I've ever seen has a stack of minor issues in the corner - cosmetic or otherwise largely inconsequential things that nobody has considered worth their time. If you just want to get your foot in the door, that's probably a good way to introduce yourself. Just find something easy, make sure you implement it well, and follow the project's rules on coding style, submission for review, etc.
Or, ask the project. "I'm new, I want to help, this is my skill set. Would someone be willing to mentor me?"
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
I'm in the beginning of starting a small open source project. When cloning the main repository one gets a complete build environment with all the libraries and all the tools needed to make an official installer file, with correct version numbers.
I like the fact that anyone who wants to contribute can clone the repository and get started with anything they want. But I'm thinking this makes it to easy for Evil People to create malicious installers and release into the wild.
How should it be structured? What do you recommend including in the repository, versus keeping on the build server only?
Leaving out your support libraries and build tools makes it a huge pain for:
anybody who just wants to try out the software, perhaps on a platform for which you haven't provided an installer, or from a newer version that you've already released
anybody who wants to contribute or hack on your project.
These are the people that you need to pull out all the stops to cater to in a project that won't have a marketing department pimping it out and won't have a full-time paid team developing new features and fixing bugs (aka, personal/open-source/hobby projects).
Nobody is going to play around with or hack on your project if its a huge pain in the ass to even get it to build, and they'll just move on to the next thing. Somebody who, for whatever reason, has an interest in spoofing your software with malicious intentions, is already going to be putting in much more effort than it would take to hunt down a few other packages to put an installer together, so you're deterring the wrong subset of users for no appreciable gain. (Consider it a form of security through obscurity. Which never works.)
Focus on making your repository accessible to users and other developers.
As an aside, people who are downloading and building software should be in the habit of checking the code anyways, or at the very least deciding whether or not they trust the distributor before installing and running stuff locally.
What you seem to be looking for is a directory layout. You tagged your question language-agnostic, but it does depend on the language(s)/framework/build tool you want to use. To give you some examples
Standard directory layout if you build with maven
For mixed languages
django and ruby can create a default layout for you
It won't stop Evil People do evil things, but it will help your potential contributors.
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 7 years ago.
Improve this question
So I have a dependency, actually two dependencies to which I'd like to make changes either right now like fixing JBSEAM-3424 or potentially in the future. The coding is not an issue - I'm capable of making the change - and I'm not seeking to fork the community project, just to have a local version as recommended by Will Hartung to get some work done.
My concern is that issues of process will come up and bite me further down the line. So SO what can I do to ensure I manage this properly. What best practices are there?
Some more specific sub-questions:
Should I change the artifact names?
How choose group artifact and
version names?
Should I import the whole source tree
or be selective?
What if I can't get the build system
working in full - should I scale it
down or try to keep it close to the
original?
Should I change the artifact names?
How choose group artifact and version names?
Keep the groupId and artifactId of the module(s) you change the same, but use a qualifier on the version to ensure that it is obvious it is a non-standard version, for example 1.0.0-simon. This is pretty common practice.
Should I import the whole source tree or be selective?
Update based on your comment: Personally I'd only add the artifacts I've changed to my local source repository. If you change another artifact later then add it to your SCM then.
What if I can't get the build system working in full
Worry about that when it happens. If the project is built with Maven it should be straightforward for you to build only the artifacts you need. If it uses an uber-ant build which you can't get working with your changes, then consider paring the build down.
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
What open source projects would you recommend as a good place for a starting open source developer? Factors that I think would be important are some obvious ones like well written code and a community that is helpful to newbies. But it might be nice if the code base is such that I can start hacking some small problems without really understanding the details of how everything works.
I'd prefer something that can be developed on Linux using C/C++/Java/Python/Scala.
Trying to pick a project like that will never work because it's not something you're passionate about. What's an open source project that you use daily or enjoy using? Go work with that one.
It really depends on what your interests are as to what project to dive into.
Rationale for a larger project (e.g. Firefox, OpenOffice, etc) is that it has many developers, a well established code base, and many small tasks/bugs to be worked out.
Rationale for a smaller project is that you will become more intimate with the code and application. You will likely get to know other developers on the team and understand the overall concept better. Additionally, your additions to the project may be more noticeable.
sourceforge has a list of projects seeking a new developer. Therer are several for your requested programming languages:
http://sourceforge.net/people/?category_id=1
Apart from developers they have more help requests:
http://sourceforge.net/people/
Pick one you use and like already.