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
Should all team members be forced to use the same IDE (e.g. eclipse, netbeans, intellij) for programming, even though the build process is independent of IDE? (Assume no IDE specific plugins etc are being used on the project.)
If everyone is using the same IDE, they can share the same configuration and work in a more consistent environment. However, if you have been working with a certain IDE for many years, being forced to use another will be frustrating and reduce productivity because you will be trying to learn the IDE instead of focussing on the problem domain.
I am interested to hear which one of these two types of teams you have worked in and which one you think works best.
Thanks
If no specific plugins are being used then why not let people use what they want? We use a mixture of Eclipse, vim and other editors to edit a mix of Java, PL/SQL and Pro*C. We all have different vim setups, and it has never been a problem.
Having said that we all use Eclipse for Java, but that is mainly because it is the best IDE for Java (for our purposes).
We are all on different versions of it though so there is not really any enforced consistency there either.
I am a fan of letting each developer choose their IDE. I've worked in standardized environments and mixed, and I haven't seen much of a difference in productivity - its more of a morale issue (people forced to use tools they don't like are less happy).
You mention Java-centric IDEs (Eclipse, NetBeans, IntelliJ). In a Java-centric environment, one can use Maven to generate project files for those IDEs, which reduces a good portion of the argument for standardizing on a single IDE - because you standardize at a lower level - the Maven project file.
The only caveat to my opinion is that I find developers that choose to use simple text-editors rather than IDEs almost always create code that is riddled with warnings when viewed in an IDE, so I frown on that practice. Of course, if someone is a wiz with emacs or textmate, etc., and doesn't generate warnings, I have no problem with them continuing with their chosen platform.
I can not say much about Java. But as for C++, if you don't agree about indentation (is it spaces, tabs, tabs of what size) the code in runtime becomes a mess and less readable.
Additional point that can be against using several IDE in the same team if peer reviews/coding is done on regular basis (i.e. part of XP or coe review).
If these are not issues I don't see why team members can not pick up their favoirite IDE.
If you get too draconian about it you'll stifle innovation and in two years you will be on an ancient version of an IDE that is wholly inadequate for your task. On the other hand if you give free reign, each developer will do his own thing and you'll have a hit in productivity.
Have a "rule of 3". Let the team pick which IDE they want to use. If some members prefer a different IDE, allow for a second alternative. By the time that some members want to move to a third alternative it is only ok if the team agrees to get rid of one of the first two.
That way you have some consistency in your dev team (with the productivity gains that go with that) but you allow for moving to alternatives without a committee deciding it.
Forcing everyone to use the same IDE only works if you employ clones. Since every person is different, they have different approaches to solve tasks. If the gap becomes a too big, allowing individuals to use their preferred tool can boost performance and morale (morale because people feel better when they believe that they have an impact).
But that must not lead to a support issue. If someone is asking for some obscure IDE (for whatever reason), they better be able to solve their issues themselves. Choice doesn't mean you get an excuse to skip work because your tool breaks all the time.
Related
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
Its my last semester of college and I have to do a big presentation in December. I plan on designing a small language that not only works, but also has some nifty features to go with it. Does anyone have any interesting syntax ideas or features that would impress my professors?
Note: I do not want to just copy a language and reimplement it. Im looking to do a little research and try some new ideas out.
I have a crazy idea.
There are compilers that compile compilers. This is fun enough by itself.
You can implement one in the MetaII style (read this other SO answer:
Are there any "fun" ways to learn about Languages, Grammars, Parsing and Compilers?)
What makes this doable for a student project is that the MetaII compiler is remarkably small, and
the technical paper (read the other answer) has everything you need in 10 pages
except some sweat, which you supply. And this fits
well in the time frame you have available (which is frankly pretty short for as student
to just sit down and whack out a compiler by himself).
MetaII's own description of itself is remarkably terse: only some 50 lines(!).
And since it can compile itself, it can compile enhanced versions of itself... so
you can use it to bootstrap much more complicated compilers. Normally, that's the
direction most people want to take it, since MetaII by itself is fairly simple.
Here's the crazy idea: You can also use it to compile less capable versions of itself.
The question is, how much can you take out, and still be able to climb back up the
metacompiler ladder? How small a compiler can you build that is still bootstrappable?
I know for a fact that MetaII has 2 items are removable, since I've done
this in the long distant past. I'm not going to tell you what they are becuase
that spoils the discovery process. But its good in a student project to take
on something that is already known to be doable, so you don't go down alleys
that have real dead ends.
One of the people I'm knew long ago apparantly tried to do this seriously. His goal was to reduce this to a very short string of characters... think of this as "compiler DNA".
Whilst I might not be able to answer your question directly, I am sure this will give you some insights from my own experience - given, for a final year project I also attempted my own scripting language (in C++) - although I am aware you're attempting a compiler so there might not be similarities. Please learn from my mistakes.
From experience:
What you imagine the scripting language will do (you type in a command, does something nifty like it fixes windows or something) and what it actually does (you type in a command, but minutes later it crashes) can often be two different things. Keep it realistic.
Aside from the brain imagining this fantastic finished product (with no inbetween), it also has a tendency of deluding itself on it's own capabilities (like 'other programmers made that mistake but I won't!'). Chances are you do make the same mistakes, or if not the same, different mistakes.
The brain has a poor ability to assess time required (if it's thinking 'it's just a hack job that'll take a month' - think again), and time it thinks is required should be multiplied between 5 to 10 times (if not more) to get an accurate idea of real scope needed. Keep to the lengthy end of the scope - worse-case scenario.
Unexpected pitfalls. Like 'how do I implement multi-precedented logic statements' and 'it's taking longer than I expected (see 3.)'. Be willing to give up complicated matters.
Design. Don't just look for ideas, think about whether or not it's a viable project, and look at how you're going to implement the groundwork before jumping to the complicated stuff (see 1.). Laying the groundwork early on can save you time. And don't forget design documents.
Research. Chances are that function you plan to write out, has already been written before somewhere. Research for it. This will save you time. Do not reinvent the wheel and do not be concerned about efficiency (university is about learning).
As one commenter said, start simple, get it working, then expand.
Best way to develop useful ideas, is to see what really bothers you about a certain task or certain scripting languages, and build it so you can eliminate or minimise that task. For example, I got annoyed by having to keep downloading files from a website and sorting it manually into specific folders - so I built a program to do that for me.
Don't go general-purpose for such a small project. Find a niche where you would like to be able to program a solution to an everyday problem. Off the top of my head, how about a constraint language for window placement in your X11 window manager of choice?
If you're just looking to have some fun, then you should try and create your own 'esoteric language'. 'Brainf**k' has kinda achieved meme status in the community (If I'm not wrong)
http://en.wikipedia.org/wiki/Esoteric_programming_language
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 2 years ago.
Improve this question
I work on developer tools for a particular product. There is a competing set of tools for the same product produced by a different company. The user-base is split roughly 50-50 between us.
Recently, the other company has introduced scripting to make their own tools extensible by end-users. This is a feature that we have had planned for our tools for a while, but it is only now that we are able to start implementing it.
My question is: should we try as much as possible to collaborate with the developers of competing product so that end-user scripts can be shared between users on the different products? We would obviously require different implementations, but share the same syntax. This would obviously be better for the community as a whole since there would be more interoperability.
The downside of collaborating like this is that the competing product's scripting language is slightly tailored towards their own implementation. We would have to jump through a few hoops to create an implementation for their scripts on our platform. Or, we would have to somehow convince our competitor to modify their scripts so that they are platform agnostic.
So, to rephrase my question: should we try to collaborate, thus making our community happier, or should we produce a competing scripting language that is more appropriate for our platform?
I realize that this is a very general question with no single right or wrong answer. What I am looking for is a good explanation of the pros and cons of each approach.
I would write something that is specifically tailored towards my own system (don't compromise your technical quality) and then release and fully support a compatibility layer that allows my competitors scripts to run on my system (make it easy for users to migrate).
I'd stay away from doing things that will try to lock people in and cripple them if they move. These tactics worked once upon a time but in this day and age don't really cut it any more. I'd even go so far as to actually (unofficially on fora etc.) help people who are having trouble porting scripts running on my system to my competitors.
Another way to ask the question (and to answer) is to wonder WHAT KIND of script language is DESIRABLE FOR USERS.
If your competitor went a lock-in route with a proprietary scripted language, then please your users (and get a competitive edge) by using a STANDARD scripted language.
Doing so will immensely increase the value of your tool as many persons ALREADY know the scripted language.
Nobody wants to learn a new language.
Would building a unified scripting language harm your customer-base or give the competitor the competitive edge?
Obviously if you want to lock in customers, go solo which will prevent your customers from easily switching over to the competitor's product (sounds a little like Microsoft tactics) or if you know your product is superior, a collaboration will allow you to get customers from the competitor in which case customers will have the choice to choose which business model suits their needs, make a choice based on the quality of the product as a whole as well as which features they really need instead of being locked into an invisible contract due to the choice they made initially.
Going the collaboration route will also put your company in a position where developers will respect your company (for not being a greedy monopoly monster) instead of boycotting it due to their "moral" beliefs in open standards.
I would say that if possible make it compatible, not so much to cooperate but to compete. Making an incompatible solution would lock you customers in to some degree (you don't have any yet with a lot of scripts - so not much gain), but making a compatible solution keeps the door open for customers of your competition to migrate (they might have some scripts by the time you ship yours).
Just my 2cents
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
I get the sense that AppleScript is more respected than AutoIt. I think that it's something you can put on your resume whereas AutoIt is not. Is that the case? Why is that? With AutoIt you can automate just about anything. Is that the case with AppleScript? With AppleScript can you make it detect arbitrary images on the screen like images in a web page?
AutoIt had a big role in getting me my current job. If you get an interview with a team of developers, bringing something new to the table is not a bad thing. Sure you are not going to find "AutoIt Developer Needed" in the want ads, but more companies need one then know it. My use of AutoIt has turned into something that sets me apart from other developers in my work.
Picking the right tool for the job is what matters and for some jobs that tool is undoubtedly AutoIt. Most developers would be excited to see something they don't know on the resume of an applicant. It tells you several things.
This person is going to bring something unique to the team.
This person is into programming because they surely didn't learn AutoIt from a required class to get their degree.
Most people who love development are going to want to talk about this odd language you know that they have never heard of. If you have some example code that would be a pain in another language you have a good shot at impressing them.
It worked for me. While you are not likely to work full time as an AutoIt developer, I use it several times a week in my work.
Both languages serve very different purposes. They both started out with similar goals in mind, but evolved differently over the years.
AutoIt has adapted GUIs and has become more of a general purpose scripting language. It also has a large following of developers that all contribute to the functionality of the language. Applescript focuses mostly on what AutoIt was originally designed for, automation.
What really separates them on this focus is that AutoIt interacts based on commands and properties of Windows, where as Applescript interacts based on commands and properties of the application it is automating. Applescript is more similar to OOP, where as AutoIt is a traditional procedural language.
Why one is more popular than the other? that is a difficult question. I actually learned about AutoIt years before I knew anything about Applescript, but that is because I worked primarily on Windows and Linux machines and rarely on Macs. It really isn't a fair comparison to say one is more popular than the other, as there is no common element between them.
Windows users will know AutoIt, Mac users will know Applescript.
What exactly are you asking here?
AppleScript is likely more widely known than AutoIt (I never heard of AutoIt and just had to look it up). Whether that means it's more "respected" or "you can put it on your resume" is entirely subjective.
The two seem to be very different things. For what reason are you comparing/contrasting them? If you're looking for which one to use for any given purpose, the first important factor would be the platform. They're designed to run on very different platforms.
There may be some things you can do in one that you can not do (at least natively or without great difficulty) in the other. The same is true of just about any drastically different programming/scripting tools/environments.
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'm responsible of finding a good way to document the software project I'm working on.
What things are important to document? Should documentation of code and design mainly be in the code in the form of comments? Should we put text files or Word documents directly in the source control togetether with code? Should we use a wiki?
Factors to think about include how easy it is for the current team to create the documentation, and how easy it is for other developers to find, correct and extend the documentation later. My experience from many projects is that developers tend to not write documentation because the system for writing it is too complex or developer unfriendly, and that after a few years, new developers can hardly find the little documentation that was written.
I'm interested in what approaches you have used in similar projects. What worked well, what did not work well, and why?
Some key facts about the project:
The platform is C# and .NET.
We use Visual Studio and Team Foundation Server for source control and work item (task) management.
We use Scrum and test-driven development and are inspired by domain-driven design.
The software consists of a collection of web services and two GUI clients.
Other clients are going to integrate with the web services in the future. The integration will be done by other developers on other teams (so the web services form a kind of API).
SharePoint is heavily used throughout the development environment. Most projects have a SharePoint site, including ours.
On our project's SharePoint site we currently have a bunch of MS Office documents on things like requirements, design, presentations for stakeholders etc. Keeping everything up to date is hard.
We also have a SharePoint wiki for the development team only, where we document things in an unstructured manner as we go along. Examples include how our build scripts are organized, our testing policy, coding guidelines.
The software is an in-house application in a fairly big financial institution.
The software is developed by a team of six people over a period of ~1 year.
The developers are consultants hired in for this project only, and will not be available to help in the future (unless the client decides to pay for it).
The client has few guidlines for how this kind of project should be documented.
I think the most important things to document are the decisions. This goes for everything from requirements to architectural choices. What are the requirements of module X? How are these requirements represented in the architecture? Why did you choose architectural pattern A over B? What are the benefits? The same goes for source code: it is common knowledge that commenting the why is way better than the how.
How you document these decisions does not matter that much in my opinion, whether you use a Wiki or a Requirements document made in Word. More important is that these documents are always up-to-date and that it is easy for anyone to access them. This can be achieved by using a wiki, or placing the documents under source control, as you say. If only a few have access to them, they are more likely not to get updated, and not to be read when necessary.
We use a Wiki for our current project and it works very well. It is easy to access for anyone (developers, managers, and customers) and a history can track changes, so you know what has been changed and why. Furthermore, we try to document the code in a meaningful way and document the major design decisions. We try not to document too much, e.g. minor things, as it is always hard to keep those things up-to-date and it is not worth the effort, imho.
Worst for me than lack of documentation is excess of documentation.
Keep in mind that yes: it's really important to document your project, but also that the major part of your documentation is always at risk of never been read at all.
So, I think that a good starting point consist in thinking of your documentation more like something that you may use to introduce new developers to your project than an over detailed description of the inner workings of your software.
G'day,
Definitely use a wiki. I'd recommend TWiki as it's an excellent and extensive implementation of a wiki without being too complicated to install and manage.
Here's a couple of initial thoughts.
Categories:
Start off with an initial ontology of what you want to capture but
allow people to add new categories or sub-categories as required,
allow people to retitle (sub-)categories as required and maybe as agreed for this one so you don't get fragmentation for multiple names for basically the same thing.
let any initial (sub-)categories wither and die if they are left empty. Do this at the end of the project as some areas may only have entries towards the end of a project.
Tagging:
Start using a tag cloud. BTW here's an excellent plug-in available for TWiki to start classifying content early on in the project. Retrofitting tags is almost impossible to do. Starting tagging early also allows people to search for information that may be there already rather than having the same info located in multiple places.
HTH I'll come back and add more points as I think of them.
First and most important, have the comments written in such a way that NDoc can parse them. This is the best way to have the code itself documented, as the developers have to change their development practices very little, and you can generate pages that explain the code without having to look at the code.
Second, getting developers to write documentation is not easy, and getting them to do it might be an exercise in futility. This is where products like Fogbugz come into play. They will help manage the development with tickets, help track check ins, and when your done an iteration, generate release notes.
In conclusion, your best bet is to find the most effective solution that fits in with the devs existing process. If it impacts their development process very little, they will be more likely to adopt the system.
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
One thing I've always found frustrating is when a library I use is no longer maintained. Even looking at update history and community beforehand, I've run into the situation where I check back later to find that the version I'm using is the last version.
Generally this goes unnoticed until a few months have passed, or some bug/limitation has been found. I run into this fairly often when coding in Python, because my desire to upgrade to a new version of the interpreter can easily introduce problems in libraries that worked fine before. My question is: what is the best response to this situation?
Do you become the maintainer of the old library? Even if you're only fixing the bugs you care about, this is still a lot of work. Especially if the library is large, complex, and has less-than-well-documented code (the case more often than not).
Do you switch to a different library (if there is one)? This is also a significant undertaking, with the potential to introduce new bugs, especially if the only alternatives approach the problem from a different angle. This can be true even if you had the foresight to write an abstraction layer for the old library's functionality.
Do you roll your own? It probably ends up as less code than the old library, since you only write the parts you care about. It's therefore easier to maintain in the future. But now you've wasted days/weeks/months to produce something that is probably less functional, and is guaranteed to introduce tons of new bugs.
I realize the answer depends on the specific case: the size of the library, whether source is available, how maintainable it is, how much of it your code uses, how deeply your code relies on it, etc. I'm looking for answers across a range of cases. What are your experiences with this problem?
Well, you've found one argument to lessen the number of external dependencies...
I've come across this in several Java projects I've audited; it seems people have a tendency to drop in a Jar found somewhere on the Web for the tiniest amount of reuse possible from it. The result is a mess of dependencies that ends up undermining the code base. I prefer to use external components sparingly.
It's probably most useful to ask what you can do before. Make a point of evaluating the future lifetime of an external component before you start using it. Do some research on how large its developer community and its user community are. Also, prefer to use a component that has one or two "lesser" alternatives which you could also use.
If there's something you're tempted to use, but it has only one or two people working on it and isn't used much beyond their own project, then you should probably roll your own - or join forces with the maintainers of the component.
I think your really answer is in how do you select third party libraries to include in your code.
If you happen to like constantly upgrading your code to the latest version of the language then by default you can only use libraries that have active communities behind them
In fact I would go as far as saying that the only time that you want to use a third party open source library is when the community behind it is large (say at least 40+ users) and it has undergone a few releases.
For a commercial library the same thing applies how long is the company going to be around and how many other clients use it.
If you can't find a library in this position then ensure that you abstract the third party library out of your code so replacement isn't hard in the future.
When the Java EE framework my employer chose went belly up, we went out and found a newer, better one. Fortunately Spring was available.
We prefer to roll our own for that very reason. We end up with full control over it, full knowledge of how it works, and we can change it any way we want. When our ass is on the line when the blame game is played, we prefer to reduce the risk and do it ourselves.
We had a situation once where we did use an external library, and it got rewritten and repurposed by the author and no longer did what we expected. We rolled over that, wrote our own version, and continued safely.
The bottom line is safety, and minimization of risk.
If the source is available, the licence is open and the library does the job really well, you have the option to fork the library. By doing this, you can also add new features to it. If the library has lots of things to fix and the code is a mess, it is better to find something else to work with.