It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 9 years ago.
In a not-so-small program, when you have not-so-few entities, in order to maintain code readability, common terms, and otherwise improve mutual understanding between team members, one have to define and maintain program vocabulary.
How do you (or your company) deal with this task, what discipline do you have, what arrangements do you introduce?
Most projects of reasonable size should have a programming/coding standards document that dictates common conventions and naming guidelines that should be followed.
Another way to help with this is through code reviews. Obviously some coordination among reviewers is required (the document helps with that, too). Code reviews help keep the greener devs and senior devs alike on track and act as an avenue to enforce the coding standards.
#Ilya Ryzhenkov,
I'm afraid most companies don't have such practice :) I've worked in the not-so-small company with multimillion LOC code base and they don't have any documentation at all (beside common coding guideline)
On one of my projects we maintained thesaurus of common terms used in our application domain and used it during code review. I analyzed .NET XML documentation diff from time to time to decide which entities\terms should be added to the thesaurus. Only means to enforce compliance with thesaurus was coding guideline.
Wiki approach proved to be non-applicable because nobody cares to update it regularly :)
I'm wondering what methods do you use at JetBrains ? I've inspected ReSharper's code in Reflector and was amazed with number and names of entities :)
Divide your packages/modules into logical groups and use descriptive and concise names. Avoid generic names except if they are really counters etc. Create conventions for groups of functions or functionality and stick to them.
Domain Driven Design is interesting here, since it encourages programmers to embrace the domain vocabulary. On top of that, there is some design conventions, which allow you to refer parts of your application using well known terms, like services, repositories, factories, etc.
Combining domain vocabulary and using technical conventions above it could be a good solution.
My team keeps this kind of information (conventions/vocabulary etc.) on a wiki. This makes it easy to keep up to date and share.
Related
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
What database would you suggest for a startup that might possibly grow very fast?
To be more specific:
We are using JSON to interchange data with mobile clients, so the data should be stored ideally in this format
The data model is relatively simple, like users, categories, history of
actions...
The users interact in "real time" (5 second propagation delay is still OK)
The queries are known beforehand (can cache results or use mapreduce)
The system would have up to 10000 concurrent users (just guessing...)
Transactions are a plus but can live without them I think
Spatially enabled is a plus
The data replication between nodes should be easy to administer
Open source
Hosting services available (we'd like to outsource the sysadmin part)
We have now a functional private prototype with a standard relational PostgreSQL/PostGIS. But scalability apart questions, I have to convert relational data to JSON and vice versa which seems like an overhead in high load.
I did a little research but I lack experience with all the new NoSQL stuff.
So far, I think of these solutions:
Couchbase: master-master replication, native JSON document store, spatial extension, couchapps and although I don't know iriscouch hosting they seem good techs.
The downside I see so far is javascript debugging, disk occupation.
MongoDb: has only one master but safe failover. Uses binary JSON.
Cluster MySQL: the evergreen of web (one master I think)
PostgresSQL&Slony: because I just love Postgres:-)
But there are plenty of others, Cassandra, Membase...
Do you guys have some real life experience? The bad one counts too!
Thanks in advance,
Karel
Unless you are already having problems with scaling, you can't really have a good idea what you actually need for the future. You should be basing your design decisions on what you need now, not when you have your best estimate of customers. Remember, you have to impress your first few customers with how well your product solves their problems before you can worry about impressing your 10,000th
That said, I've found that its almost always neccesary to have basically everything:
A smart/powerful database for the important data and queries that are part of the current application. For this I have no choice ahead of PostgreSQL/PostGIS.
A document database (sometimes called NoSQL) to record forever anything that has passed through your system. It was an invalid or useless request a year ago, but now you have an application that can use that kind of data, and the vendor finally gave you the API spec you need to parse it, I hope you've got it around in a form you can work with it. At my current organization we are using CouchDB for this and it's proven to be a great choice so far.
I have to convert relational data to JSON and vice versa which seems like an overhead in high load.
Not really; the expensive stuff is IO and poorly written queries. The marshalling/unmarshalling is pure CPU, which is about the cheapest thing in the world to grow. Don't worry about it.
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
Besides practice(practice and more practice) reading books and forums, analyzing others people code is a must in order to have a career in this field.
The problem is that I'm a student(feels like always on learning stage) but sometimes i can't solve the problems by my own. I was thinking that on public open source repositories might be the answer I'm looking for.
My question is how can i find the answer to some of my problems in open source projects/community? Do you have any tips to share for me?
ty
A few things for learning problem solving skills related to software developement (once you've found a project that you are interested in that is also written in a language you feel comfortable with) are:
Sign up to the mailing list
Lurk about on the project's IRC
channel (assuming they have one)
Read through bug repots (the open
ones to try solve them, and the
closed ones to see how others solved
them).
and of course discuss discuss discuss, if you think you have a basic grasp of the problem at hand but need clarification on some issues don't be afraid to ask your peers.
Hope this was of at least some help,
Welcome to the open source world and good luck!
Analyzing others people code is a must... I'm a student... public open source repositories might be the answer?
The problem with open source is that the quality varies too much.
(There's lots of my own code sitting in public open-source repositories that I wouldn't want anyone to try to see, let alone learn from.
And yet some of my code, the code I have lavished time and attention on, is very good—or so my peers tell me.)
So you don't want to pick an open-source project and learn from J. Random Hacker. You want to learn from the best hackers.
Here are some strategies:
If you're a student, you have acccess to teachers. One or two of them may have an idea about software. Ask them what is worth reading—what you will learn from.
Look at conferences and journals that publish about software: SIGPLAN, SIGSOFT, USENIX, Software—Practice & Experience, Journal of Functional Programming. Read about systems that look interesting to you. Write to the authors and ask them if they recommend you try to learn from their code. Listen carefully to what they say; most of the best hackers know they can do better. If you extract a grudging admission, with a bunch of caveats, that maybe there is something to learn there, you've found the right person.
If you're learning C, a lot of the old Bell Labs stuff is really worth looking at (and a lot isn't). I admire the work of Jon Bentley, Brian Kernighan, and Rob Pike, among many others. You can download and read the source of the original awk, or Pike's interpreter for Newsqueak.
Popularity does not correlate with suitability for learning. The GNU tools are very popular, but almost anyone who has seen both will tell you that you will learn more from the Bell Labs versions. And Linux is very popular, but people I trust who work in the field tell me that if you want to learn about operating systems, you should study BSD. I myself work in the field of compilers and can tell you that if you want to write a compiler in C, the model to emulate is the little-known lcc, not the wildly popular gcc.
Finally, I highly recommend the work of Richard Bird, Hans Boehm, Ralf Hinze, and Phong Vo (two Haskell programmers and two C/C++ programmers).
What I've found useful over the years, is to validate your code, go through coding conventions and best practices for various languages. Open Standards are the inevitable part of Open Source Software. In order to maintain a successful OSS project, it has to have some common ground in the community, so for instance:
if doing some (X)HTML and CSS, always do it by the W3C standards. Passing validation will in itself improve your skills greatly. Use tableless markup (see Benefits of tableless design);
if doing some PHP, go through PEAR coding standards which is the de facto standard for all OSS PHP projects;
if doing some Flash Platform coding in Flex/ActionScript, see Flex SDK coding conventions and best practices;
if doing some Java, see Code Conventions for the Java™ Programming Language.
Lastly, but not less importantly, research Object oriented programming and various architectures used for software development, e.g. the MVC pattern.
... analyzing others people code is a must in order to have a career in this field.
I wouldn't say that is correct. Certainly it is not a must. Reading other people's code doesn't usually explain why they chose to solve a problem a certain way, and what alternatives they considered and then dismissed. Besides, it is not uncommon to find open source code that is badly designed and/or badly implemented.
The problem is that ... but sometimes i can't solve the problems by my own.
Ah. Well the solution to that is to practice, practice, practice, and not be afraid to make mistakes. Be self-critical, but don't let this stop you from "having a go". The more you do your own problem solving, the easier it will become.
Ask, ask, ask, ask if you come across a particular problem or solution that you don't understand. Make a good-faith effort to solve the problem or to understand a solution, share your thought process, and ask. SO is an excellent place for that, which you undoubtedly have already discovered. Good luck!
As other said, ask to the mailing list of the project, anyway some of open source developers are not willing to help (unfortunately) for this sort of things.
In this situation I search answers by myself: pick up a terminal and use grep.
Guess naming of classes/functions that involves your problem you will find the way toward the module where the interesting bits are written.
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
How to successfully implement democratic (non-BDFL controlled) type of management for the open source project?
More specifically - for the project using distributed source repositories.
What style of communication is best to adopt in such environment?
How to encourage merging branches into the master?
I am mostly interested in establishing the situation where people can directly merge into the master branch under the "social contract" agreement that they follow the project roadmap (which they themselves help to define) and that code they commit is tested.
I specifically want to encourage workflow
define the problem->define requirements and specific metrics of success->architect->build and test
The reason is that - I often see emails like here is the problem and here is how I think it should be solved
Immediately somebody else jumps in and starts a fight.
Not productive at all.
Often disagreement of that kind stems from not being on the same page on the problem definition, requirements or architecture. Or sometimes just because nobody even thought about such things.
How to encourage people to analyze the problem properly, share great ideas and select the best solutions?
How to organize communication so to avoid silly fights, make good decisions without being overly bureaucratic and move along at a good pace ?
Would you have any suggestions? Are there examples of projects managed this way?
How do you think adoption of distributed revision control instead of centralized affects the style of project management?
edit: found some interesting links in related questions
http://gettingreal.37signals.com/toc.php
http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/
Sorry for this somewhat off-topic answer (i.e. one not addressing directly the question). Please edit at your heart's delight!
Projects _do_ need executive governance!
Such may come from a single Benevolent (or not) Dictator, or a [IMHO, small] group, possibly open, of diverse but like-minded individuals. A standard joke on this is that: "The group should be made of an odd number of members, and 3 is already too many"; in truth, small collegial committees can be very effective.
This requirement for a "non fully democratic" decision making entity is however somewhat aligned with the processes suggested in the question. To effectively harness the good will of contributors to the project, the executive team needs to
be perceived as legitimate
communicate effectively
empower "the masses" to contribute with roadmap definition, problem identification, solution scoping and all other design-level tasks. (All the while it remaining clear that in the end, and after all has been said, final decision will be done in committee.
DELIVER a good and vibrant product (BTW by adopting agile development processes, the time between deliveries is lessened)
compromise when needed
advocate the interest of pooling resources in a coordinated fashion, rather than branching out.
Share the glory!
To support all of this formal documentation and processes are very useful. For example, the define the problem->define requirements and specific metrics of success->architect->build procedure indicated in the question can be implemented in the form a single collaboratively edited document (wiki-based or other), i.e. one per issue/idea. This document is templated with a defined format: required attributes such as date, initial posting info... and sections which are opened (and closed) for editing following a given schedule. This allows keeping a clean(er) record of the way the collective though of a given issue, what was suggested etc, what was [authoritatively] decided and why.
With such a process, the community feels engaged and hopefully individuals not too disappointed when the eventual decisions do not go "their" way. They can read and comment on the what and why of the decisions.
Another useful approach is to reward effective participation by informally (or factually) provide more weight to the contributors who effectively help with the project. The more active members can either gain their way into the "inner circle" or be handed-out leadership roles on subsets of the project.
Finally, the leaders of a project (whether in the context of a "democratic" or of a "partially dicatorial" leadership) need to be ever vigilant about "peace keeping". Contributors to Open Source projects are typically energetic, smart and opinionated individuals; conflict of opinion, conflict of personalities, impatience etc. is to be expected. These clashes however can be eased by systematically addressing issues with clear facts, moderating/editing aggressively against name calling and non-productive forms etc.
Originally posted on MetaOptimize.
Constitution for Governance of Open-Source Projects (v20100227)
Let it be affirmed that the primary goal in instituting governance of an open-source project be to ensure the long-term health of the project.
Accordingly, the default bias should be towards openness and inclusiveness.
However, policy should be changed as issues present themselves, in order to maintain the long-term health of the project.
For the model of decision making, we favor a "do-ocracy".
The people who contribute the most generally command the respect of the community.
Alienating them is the best way to derail the project.
The repository should be open the committers, given that commits can easily be reverted and commit-access easily revoked. This is preferable to alienating potential committers.
To ensure transparency for developers new and old, and allow them to decide their involvement in a project based upon the history of the project, their should be transparency and openess in the inner working of the project. For example, the email archive should be public.
Lastly, let us remember that too much red-tape gets in the way of progress. So red-tape and other barriers to contribution should be avoided, and only added as issues present themselves.
This Constitution can and should be amended as issues present themselves.
Therefore be it resolved.
access to repository
there are several options ranging from one controlling committer to anyone can commit - but upon social agreement that they respect the project guidelines and the roadmap.
in my opinion distributed repository allows you to be more relaxed with who you allow to commit, because there are multiple backups and the repo becomes virtually unbreakable.
on a separate note - anyone can commit approach - which I would like to test out - sounds more like a "wiki". I can directly compare this with my experience managing a wiki (nmrwiki.org): where despite complete openness - where not even user registration is required to edit the resource, people are often wary about "breaking stuff" and this worry becomes a mental barrier to making a contribution. So a permissive approach to repository management may just work.
Communication style:
email and mailing lists:
discuss everything concerning the project in public (?)
when asking questions - do not bundle
questions with your own opinions
encourage people to propose more than one solution
ask people to weigh pros and cons
be brief and to the point
avoid frivolous language that can be perceived negatively with people that do not know you well
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
I have an interesting idea for a new programming language. It's based on a new programming paradigm that I've been working out in my head for some time. I finally got around to start working on a basic parser and interpreter for it a few weeks ago.
I want my new language to be successful and I want to eventually create a community around it when it's ready to release. The idea behind it is fairly innovative, so I don't expect it to gain a lot of ground in the business world, but it would thrill me more than anything else to see a handful of start ups use or open source projects use it.
So taking those aims into account, what can I do to help make my language successful? What do language projects do to become successful? What should I avoid at all costs? I'd love to hear opinions or stories about other languages -- successful or not -- so I can think about them as I continue to develop.
So far, the two biggest concerns on my mind are finding a market, access to existing libraries, having amazing tool support. What else might I add to this list?
The true answer is by having a beard.
http://blogs.microsoft.co.il/blogs/tamir/archive/2008/04/28/computer-languages-and-facial-hair-take-two.aspx
Although not specific to new programming languages, the book Producing Open Source Software by Karl Fogel (available to read online) may be contain some hints to the issue of making a community around your new programming language.
In terms of adoption of programming languages in general, it seems like the trend lately has been to have a rich library to make development times shorter.
As there isn't much detail on what your language is like, it's hard to determine whether adoption of the language is going to depend on the availability of a rich library. Perhaps your language will be able to fill a niche that has been overlooked by other languages and be able to gain users. Or perhaps it has a slick name that will draw people in -- there are many factors which can affect the adoption of a language.
Here are some factors that come to mind when thinking about recent successful languages:
Ability to leverage existing libraries in the new language.
Having an adapter to external libraries written in other languages.
Python allows access to code written in C through the Python/C API.
Targeting a platform which already has plenty of libraries available for use.
Groovy and Scala target the Java platform, therefore allowing the use of and interoperation between existing Java code.
Language design and syntax to allow increased productivity.
Many dynamically-typed languages have gained popularity, such as Ruby and Python to name a couple.
More concise and clear code can be written in languages such as Groovy, as opposed to verbose languages such as Java.
Offering features such as functions as first-class objects and closures which aren't offered in more "traditional" languages such as C and Java.
A community of dedicated users who also are willing to teach newcomers on the benefits of a language
The human factor is going to be big in wide-spread support for a language -- if people never start using your language, it won't gain more users.
Also, another suggestion that I could add is to make the development of your language open -- keep your users posted on developments in your language, and allow people to give you feedback. Better yet, let your users take part in the decision-making process, if you feel that is appropriate.
I believe that by offering ways to participate in the bringing up of a language, the more people will feel that they have a stake in the success of the new language, so the more likely it will gain more support.
Good luck!
Most languages that end up taking off rapidly do so by means of a killer app. For C it was Unix. Ruby had Rails. JavaScript is the only available programming system common to most browsers without third-party add-ons.
Another means of success is by fiat. This only works if you have significant clout. For example C#, as nice as a language as it might be, wouldn't be any where near as popular as it is now if Microsoft had not pushed it as hard as it does. Objective-C is the language of MacOS X simply because Apple says so.
The vast majority of languages, though, which lack a single killer app or a major corporate backer have gained success through long term investment of their respective creators. Perl and Python are prime examples. C++ has no single entity behind it, but it has evolved as the needs of developers have changed.
Don't worry about trying to make the language be successful; worry about using it to solve real problems and make real money.
You'll either make lots of money from using this language, or not. Once you have lots of money, others may care how you did it. Or not, either way you have lots of money.
If you don't make lots of money, nobody will want to know how you did it.
Edit based on comment: I define successful as people using it, and people use languages to solve problems, most for profit, thus successful == profitable.
In addition to making the language easy to use (which has several meanings), you should develop a comprehensive library that covers and also provides a good level of abstraction over (the following most important areas):
* Data structures and manipulation
* File I/O support
* XML processing
* Networking (plus web based technologies like HTTP/HTTPS)
* Database support
* Synchronous and asynchronous I/O
* Processes and threads
* Math
A well thought out framework that makes rapid development faster (and easier to maintain) would be a great addition. For this, you should know the currently popular frameworks well.
Keep in mind that it takes a lot of time. I think it took python about 10 years (someone please correct me if I'm wrong).
So even if your community still seems small after say, 5 years, that's not the end of the story.
"It's based on a new programming paradigm that I've been working out in my head for some time."
While laudable, odds are really good that someone has already done something with your "new" paradigm.
To make a language usable, it must build on prior art. Totally new is not a good path to success. My favorite example is Algol 68.
Algol 60 was wildly popular (back in the day, which is a while ago, admittedly).
The experts wanted to build on this success. They proposed some new paradigms, the effort split into factions. The purists put the new paradigms into Algol 68; it disappeared into obscurity. Some folks created a different version of Algol, called PL/I. It did not have any really new paradigms. It actually went somewhere and was used heavily. Another group created Pascal -- it didn't have much that was new -- it discarded things from Algol 60. It actually went somewhere ans was used heavily.
Your new paradigm must have a clear and concise summary so people can fit it into a context of where the language is usable, how it can be used, what the costs and benefits of using it are.
A "new programming paradigm" causes some people to say "why learn a completely new paradigm when the ones I have work so nicely?" You have to be very clear on how it helps to have a new paradigm.
The language and libraries must work, and work very, very well. A language that isn't rock-solid is worthless. In order to be rock-solid it must be very simple.
It has to have a tutorial that will help anyone get started with your language.
Good Framework for Common Tasks
Easy Installation/Deployment
Good Documentation
Debugger/IDE and other Tools
A popular flagship product that uses your language!
Good documentation, including a detailed reference manual as well as simple examples to get people started quickly.
Good library support so that people can actually write useful programs.
Most popular languages seem to be very strong in either or both or both of those.
Use Trojan Horse approach
C++ - The Forgotten Trojan Horse
An interesting article on why C++ can grab the heart of programmers successfully.
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 9 years ago.
I am a student studying software development, and I feel programming, in general, is too broad of a subject to try to know everything. To be proficient, you have to decide which areas to focus your learning and understanding. Certain skill sets synergize with each other, like data-driven web development and SQL experience. However, all the win32 API experience in the world may not directly apply to linux development. This leads me to believe, as a beginning programmer, I should start deciding where I want to specialize after I have general understanding of the basic principles of software development.
This is a multi-part question really:
What are the common specializations within computer programming and software development?
Which of these specializations have more long-term value, both as a foundation for other specializations and/or as marketable skills?
Which skill sets complement each other?
Are there any areas of specialization that hinder your ability of developing other areas of specialization.
Ben, Almost all seasoned programmers are still students in programming. You never stops learning anything when you are a developer. But if you are really starting off on your career then you should be least worried about the specialization thing. All APIs, frameworks and skills that you expect that gives you a long term existence in the field is not going to happen. Technology seems changing a lot and you should be versatile and flexible enough to learn anything. The knowledge you acquire on one platform/api/framework doesn't die off. You can apply the skills to the next greatest platform/api/framework.
That being said you should just stop worrying about the future and concentrate on the basics. DataStructures, Algorithm Analysis and Design, Compiler Design, Operating system design are the bare minimum stuff you need. And further you should be willing to go back and read tho books in those field any time in your career. Thats all is required. Good luck.
Sorry if I sounded like a big ass advisor; but thats what I think. :-)
Not to directly reject your premise but I actually think being a generalist is a good position in programming. You will certainly develop expertise in specific areas but it is likely to be a product of either personal interest or work necessity. Over time the stuff you are able to transfer across languages and problem domains is at the heart of what makes good programmers.
I think the more important question is: What areas of specialization are you most interested in?
Once you know, begin learning in that area!
I would think the greatest skill of all would be to adapt with the times, because if your employer can see this potential in you then they would be wise to hold on tightly.
That said, I would advise you dive into the area YOU would enjoy. Learning is driven by enthusiasm.
Since my current employ is with an internet provider, I've found networking knowledge particularly helpful. But someday I'd like to play with 3D graphics (not necessarily games).
Go as deep as you can starting off in one environment, win32, .net, Java, Objective C... whatever.
It is important to build the deep understanding of how X works... so that you can translate the same concepts into other languages or platforms/environments, if you so desire.
"Are there any areas of specialization that hinder your ability of developing other areas of specialization." Sort of, but nothing permanent i think.
Since I am relatively green myself (less than 4 years) I come from a really OOP mindset. I've rarely jumped out of .NET, so I had a hard time on one job when coming into contact with embedded code. With embedded programmers fearing object creation and the performance loss of inheritance. I had to learn the environment, seriously low memory and slow clock times, they were coming from. Those are times to grow, I had a better time at it because i understood my area pretty well.
I will say if you pick something to specialize in for marketability and money, you will probably burn out fast. If you do start to specialize pick something you enjoy. I love GUI programing and hate server side stuff, my buddy is the opposite, but we both love our jobs. If he had to do my job, and I his, we would both go insane out of boredom.
As a student I'd recommend forgetting about what you're programming and focusing on the software process itself. Understand how to analyse a problem and ask the right questions; learn every design pattern you can and actually apply them all to gain a real understanding and appreciation of object-oriented design; write tests and then code only as much as you need to in order to make the tests pass. I think the best way to really learn is to just code as much as you can - the language and the domain aren't important, browse sourceforge and freshmeat for any interesting-sounding projects and get involved. What's important is understanding the fundamentals of software engineering.
And yes, this includes C. Or Assembler. This is the easiest way to get a good understanding of how your computer works and what your high-level code is actually doing.
Finally, never stop learning - Service-oriented architecture, inversion of control, domain-specific languages, business process management are all showing huge benefits so they're important to be aware of - But by the time you finish studying and join the workforce who knows what the next big thing will be?