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 10 years ago.
Over the years, I have tried many times to find a good, easy to use, cross platform tool for some basic software system diagramming. The UML tools I have tried seemed to get in my way more than help. So far, the solution I keep returning to is Visio, which is both Windows-only and expensive. Although its far from ideal, it does provide some basic building block and allows things like grid placement and zooming. I wanted to see if there is a great tool out there that I'm just missing that fits at least some of the criteria mentioned.
Graphviz FTW!
What could be more hardcore than writing a text file to convert into a diagram etc...
GUI, we don't need no stinkin' GUI!
You could try DIA, though it is a bit basic it will keep out of your way when doing pure diagrams.
http://www.gnome.org/projects/dia/
Well, I guess you mean for Windows. Otherwise for the Mac, nothing I know can beat OmniGraffle. Not only it is so easy my grandmother could use it, it can actually make really "beautiful" diagrams. It is really not too expensive (version 5 is now $99, but older ones used to be less than $40; still got a cheap one) and it can do it all, network diagrams, flow charts, UML digrams, UI mockups, etc. The app is clever, it thinks for you in a way, e.g. it will detect that you try to align objects on a line or have equal spaces between them and offer you hinted drag'n drop to make sure these criteria are met. As I said, it's really easy to work with OG.
And it can even also existing Xcode project (the standard Mac IDE for programmers) and automatically generate graphs from your source code. A complete UML chart by just pulling your Xcode project onto the icon :-) I guess it would be great if they could port that to Linux or Windows, but I'm afraid it will never happen.
Enterprise Architect (http://sparxsystems.com) is the best and very affordable.
I've used Edge Diagrammer... It does what you want simply and quickly. Supports grid placement and zooming. It's Windows-only, and it's gotten more expensive than I remember, but still cheaper than Visio.
I like Visio
If you have to use software, Visio is my favorite. (I get it for free through my school's CS program)
But... I find the best tool out there is a 17" x 11" sketchpad, sure it's made for artists but nothing beats a massive piece of paper for figuring out design problems.
The most productive diagramming, in my experience, is done on the whiteboard.
I capture in Visio, though, it has more tools and shapes than anyone else, and you can extend it to do code generation.
Sometimes I use yEd. It is a Graph Editor, but it is perfectly able to be used as a diagramming tool.
MagicDraw is quite good IMHO.
The best free solution that I'm aware of is Dia. It's marketed as a casual Visio replacement.
There's also Kivio, which I've heard good things about but haven't personally used. That one's multi-platform and free.
I use Violet UML Editor for most of my diagrams. It's not cluttered with code reverse engineering and code generation features and makes creating elegant simple diagrams very easy. Best of all it's free.
TopCased http://www.topcased.org/index.php
BOUML: http://bouml.free.fr/index.html
Related
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 11 years ago.
my development style brings me to write a lot of throw-away "assisting" code,
whether for automatic generation of code parts, semi-automated testing, and generally to build dummies, prototypes or temporary "sparring partners" for the main development; I know I'm not the only one...
since I frequently work both under windows and Unicies, I'd like to non-exclusively focus on a single "swiss army knife" tool that can work in both the environments with limited differences, that would allow me to do usual stuff like text parsing, db access, sockets, nontrivial filesystem and process manipulation
until now under unix I've used a bit of perl and massive amounts of shell scripts, but the latter are a bit limited and perl... despite being very capable and having modules for an incredible array of duties, sincerely I find it too "hostile" for me for something that goes beyond 100 lines of code.
what would you suggest?
scripting is not a requirement, it would be ok to use more static-styled languages IF it makes development faster (getting programs to actually do their work and possibly in a human readable state) and if it doesn't become nightmarish to handle errors/exception and to adapt to dynamic environments (e.g. I don't like to hardwire data /db table structure in my code, especially by hand).
I've been intrigued by python, ruby, but maybe groovy (with its ability to access the huge class library and his compact syntax) or something else is better suited
thanks a lot in advance!
(meanwhile, on a completely different note, scala looks really tempting just for the cleanliness of it, but that's - probably - a completely different story, unless you tell me the opposite...?)
Python is arguably one of the best choices. Its biggest benefit is that it has a huge built-in library for doing all sorts of stuff. It is also mature, very cross-platform, actively developed, and has many support options (mailing lists, newsgroups, etc).
In addition, it has a built-in GUI toolkit (tkinter) for those times when you need to write a quick GUI to get input from a user or display output from a running process. And if you don't like tkinter, there are other cross-platform GUI toolkits available.
I suggest Python.
For me it has a sweet spot of good libraries, documentation, community, cross-platform functionality, and ease of writing/reading.
It fills a similar niche to Perl's, but if you find Perl to be 'hostile' for longer scripts, you will probably like Python, especially when compared to Ruby, which feels more Perl-y, IMHO.
As an aside, all of these are quite easy to just try out - why not do that?
Then you can decide for yourself instead of trusting the questionable wisdom of an online forum (:
I think that Python and Ruby are your best bets, depending on exactly how you think and code.
I personally find Python EXTREMELY readable and its syntax is highly intuitive. I've heard Python described as "pseudo-code plus colons."
On the other hand, once you get around its slightly bizarre syntax, Ruby makes for high-speed development. It's built around DRY principles and convention-before-configuration, which is great for rapid prototyping.
There are other languages--especially Haskell and the Lisp dialects--that can make for super-rapid prototyping, but they don't have as large a supportive community, so there's a shortage in library and discussion supply.
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 have a great idea for a 3D network game, and I've concluded that it is possible to write it in Java as an applet which will live under the web browser, just like a full software in C++. And it will look and feel the same.
The main advantage of Java on C++ is that with Java you can play without downloading any software. I have already thought about the download of the graphics, sound, etc but I found a solution for it. RuneScape just proves that it is possible.
So my first question is, should my game live on a web browser or on the operating system? I think that in a web browser it is much more portable, although you need install Java and stuff. But the fact is, that most MMO games are currently not in the web. If you suggest in a software so please suggest a language either - C++ or something more productive like Python or C#?
So after choosing a language, I need a graphics solution. Should I write directly with OpenGL/DirectX or use a game engine? What game engine should I use? Ogre? jMonkeyEngine?
What's your opinion?
Thank you!
P.S: Please don't use answers like "Use what you know".
Despite your last point, use whatever you can, and what will provide the biggest user base possible.
Applets are old, and no longer used as extensively as they used to. Flash or Silverlight are the "standard" for web games now. It may be worth checking out JavaFX based your interest in using Java, it's supposedly a replacement for what applets should have been. I've not actually used JavaFX, nor do I hear much about it, take that as you wish. The biggest benefit of deploying to the web is as you've said, the user base is larger and people are more likely to give your game a play. The downside is that you end up using the likes of Flash or equivalent for the development process.
If you go down the route of building a standalone application, you can use whatever you want. C++, Java, C#, Python and so on are all viable options. You can make games in most languages. C++ is the industry standard but ignore this fact. You can make amazing looking and performing games in any language if you are a hobbyist developer. What I'm trying to say is that unless you are building the next big hit, using C++ can be avoided. In contrast to web applications, your users will require a framework/API that you use. For example, they'll need OpenGL/DirectX/XNA and so forth. As for XNA vs DirectX vs OpenGL? It matters not, your language choice will most likely dictate your choice of graphics API/Framework. So I'll leave this point up to yourself for research.
As for should you use an engine? It depends.
Are you making a game which is complex enough to warrant an engine?
Do you wish to just focus on the game, rather than the engine?
Do you feel comfortable learning an existing engine?
Do you feel comfortable producing the required components (collision etc..) on your own?
Other factors come into this, but it may be worth just focusing on the game at hand. You can easily write a simple enough engine for what you require. By doing this, you'll avoid licensing and deployment issues.
One option to consider is the Unity 3D game engine - in addition to being a fairly powerful development tool, it has several cross-platform deployment options. You can build both a stand-alone executable (for Windows and Mac, not yet Linux), and a web-browser version, which answers your first question about deploying on the web versus OS. You can do both.
It also uses both Javascript and C# (and Boo, a variant of Python) for scripting languages. These are based on Mono, the Open-Source version of .NET, so it's not just a gaming platform, but has access to all of .NET's abilities (well, those implemented in Mono anyway).
See the Licensing page for a long list of Unity's features (the Basic version is free). And check out the list of Unity-based games, of which the first is Tiger Woods PGA Tour Online, by Electronic Arts.
A game that just runs as an applet will not be percieved as a real game to most hardcore gamers.
If you want a game that is played only by noobs, the java might be an option, otherwise drop it and stick to a language that allows to actually produce executables.
Talking about the library, there are not so many you can't try them all and chose the one you like the most, so... do just that.
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 10 years ago.
Lately I've been job hunting, and for the most part, they would ask me what type of IDE I like to use.
Now, I usually answer with;
Well it all depends on what language I'm developing it in. If it's Java then it would be Eclipse, if AS3 then either Flash CS4 or Flex Builder 3. For HTML, CSS, PHP, and Javascript, I prefer to use PsPad. (almost identical to Notepad+ or textmage).
Now why is it that they always seem to become immediately disgusted with the fact that I said PSPad? Truth be told, I don't like to use DreamWeaver because I feel like it's bloated. I mean to each his own I guess ... but I've tried using it and I honestly work faster with PSPad.
Should I start using Dreamweaver just to put in my resume?
Theoretical Advice
It's quite reasonable not to like IDE's, though you do need to acknowledge their usefulness, and everyone has their own most efficient ways of working, which makes sense.
Practical Advice
You can't deal with recruitment agents logically, I'm afraid. You need to check their checkboxes, and get past them, to talk to someone real.
Once you get into a real interview with a programmer, be honest about everything, about why you don't like IDE's (especially DreamWeaver) and then you can just hope for the appropriate outcome.
But with recruitment agents you need to appreciate that they don't understand anything about our industry; and you typically need to give them the answers they want.
I'd say your are "familiar" with DreamWeaver and leave it at that.
Maybe they don't know what PSPad is - I didn't. As for Dreamweaver, I would actually look down on somebody who uses Dreamweaver. It's much better to be able to code from scratch.
And to answer your question - it's definitely not wrong to not prefer a single IDE for everything. You should use whatever tools you feel comfortable with, and if it's different for each language, then so be it.
No, just like it's not wrong to prefer:
Horses over cars;
Kerosene lamps over electrical lighting;
Aqueducts over water pipes;
Storing food in a cold cellar instead of an "icebox";
Punch cards over keyboards and visual displays;
and so on.
Sucks that we have to go through people who care not about the programmer but the programs we use!
I mean I think I lost a few chances just by trying to explain that I am decent with HTML and CSS but don't use Dreamweaver (because I cant afford it).
Though I am not that worried, I did eventually stumble across a person who does understand these things and love working for him. So no it's not wrong, you're just unlucky to have come across wrong recruiters.
Good luck finding a job though!
PS It doesn't take more than 10 minutes to get familiar with an IDE, so always a plus to try out some (so you're not completely lost later).
One way to spin such answers is to make yourself the expert. So you could say something like, "I'm familiar with Dreamweaver, but once I got really good at coding HTML, CSS etc. I found it more efficient to just use a really fast and simple text editor like PSPad."
I used the same trick after I worked in C++ and was applying for a Java job. In that case, it went like this, "Well, the nice thing about having started in C++ is that it's such a rich and low level language that once you've done that, Java seems really easy by comparison."
The recruiter doesn't know what DreamWeaver is -- they just know what a commission is. Show them you'll make them one by selling yourself to their principle and they'll send you out to interview more often than not.
Look: when you're job hunting the person who is looking at your resume is either a:
Human Resource person (Needs a person to fill a position or just interview)
Head Hunter (Needs a body to fill a job so they can get their placement pay)
IT Manager (Needs a qualified soul for the best price).
Depending on the person interviewing you over the phone or in person they are just trying to get the best candidate for a position. Sometimes they have prepared questions to see how much you know, how you think and do you match up to your resume.
I went to a .NET code camp once and a head hunter was asked how one goes about showing the interviewer their experience. The head hunter said show them your work:
Bring a laptop with samples of your work.
Print out code sample.
Direct the interview to a website with samples of your work.
Things like this get you past the IDE question real quick.
As silky alluded to above, it's probably a simple mechanism in use by the HR agency to filter out candidates. If you're not using an IDE on the selected list, you're filtered.
For me, when interviewing, I would find somebody who says they use VIM or Emacs as their IDE to be a more advanced developer than perhaps somebody using Notepad.
Last time a CTO asked me what I use, I immediately said "Emacs, of course". He said, "OK, now I'm interested!". I've been working there since.
(I don't know why PSPad would be any worse than Dreamweaver or Eclipse. I find all IDEs hard to really customize. Everybody I work with has gobs of elisp, much of it shared, to make it much more productive for our project.)
Maybe you're talking to the wrong people for the kind of job you want. Where are you finding these "they" who ask you this?
It's certainly not worse than depending on one.
I use EMACS as my primary programming environment. It has a few big advantages:
It's available practically everywhere.
You can use it without having a window system installed.
You can use it over SSH.
It lets you edit multiple files at the same time.
It understands most programming languages.
You can run subshells.
Oh, you can read your email from within it, too.
This question has no good answer. It depends on the culture of the place you're interviewing for. At my current job, I play up my Unix experience and can impress other folks that also enjoy non IDE toolsets. vi, one liner scripts, etc. At my former gig, people were enamored with Visual Basic, and thought the command line was horrific. I'll bet if you were interviewing for the company that develops PSPad you would not have had the same result. ;-)
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 10 years ago.
Can anyone recommend a good book for learning VHDL? Or failing that, any good resource?
The unfortunate problem with VHDL is that there are loads of outdated, poorly styled and outright wrong resources out there; both electronic and in print.
Part of the art of mastering VHDL is knowing how to filter these out. The following is the filtering I did in my previous life as a hardware designer. I hope it is helpful to you.
These are the things you want to read, or own, or download:
Book: "The Designer's Guide to VHDL" by Peter J. Ashenden (ISBN 1-55860-270-4). It does not waste your time by telling you to use obsolete or vendor specific libraries; it does not explain VHDL assuming you are a software engineer who wants to know about HDLs; it does not explain VHDL by assuming you are a hardware engineer who wants to know about HDLs. It does not advocate a vendor and its solutions (working with a particular vendor toolchain is a separate issue, and I've found it helpful to keep learning VHDL and vendor-specific separate). What it does do is introduce VHDL from the right perspective: as a language used to describe discrete event systems, from which smart programs can extract something that can end up as being hardware. It also describes what the standard language constructs are, which standards of the language exist, and what are their specific properties. Modern tools are ever more adherent to the standards, so this info is way more useful than a bunch of analogies that some other books (to remain nameless) seem to purport. Buy it, it's worth every cent.
The newsgroup comp.lang.vhdl is inhabited by people who are very knowledgeable about modern VHDL and can give you sane advice if you can ask questions well. To be able to do the latter, read the book mentioned above. Wading through numerous VHDL forums is in general a waste of time, as the information content there is generally drowned in noise.
Know your tools. Get yourself a PDF of the toolchain you will be using and know it very well. The more, the better. Especially know their limitations. Tools often have idiosyncrasies that you will need to work around or play along with to get things just right. For instance, you will probably want to write the portable behavioral code; except for the parts that are either technology-specific, or are such that your tool happens to synthesize them wrong.
Know where to find sane VHDL resources. An example of a sane resource is the Hamburg VHDL archive (at: http://tams-www.informatik.uni-hamburg.de/research/vlsi/vhdl/) I found through using the sampling method that the signal-to-noise ratio on that particular website is pretty high. Use it.
A fairly obscure book about hardware synthesis (for the really curious; and written from an academic perspective) is Giovanni de Micheli's "Synthesis and Optimization of Digital Circuits" (http://si2.epfl.ch/~demichel/publications/mcgraw/index.html) which may shed some light on the hardware synthesis methods -- though a substantial body of work has been done to improve the results given there since. You may want to borrow this one from a nearby library and leaf through it.
I like the book called "Circuit Design with VHDL", from Volnei A. Pedroni. It focuses on synthesizable VHDL, that is what you will need to code for real chips, not only for simulation.
A great textbook to start out with is: Fundamentals of Digital Logic with VHDL Design
I remember starting out with this to get a quick overview.
I found the Low Carb VHDL Tutorial to be excellent when I was learning VHDL. Now even more since the author of Low-Carb VHDL Tutorial has turned it into an open-source book titled Free Range VHDL.
I recommend the Chu, Pong P.: RTL Hardware design using VHDL. John Wiley & Sons Inc., 2006.
When learning any sort of HDL (Verilog, VHDL...) it is important to keep one thing in mind. It is not software programming and things work in parallel. That being said, I find that the best way to learn any HDL is to learn how to think in hardware and describe the hardware (that's why it is called a hardware description language).
So far, I have rarely seen books that show you how your HDL gets translated into hardware. I've read through one when I was at Synopsys (pages filled with code and schematics) but it was an internal publication. However, even lacking this book, you can still see how your code gets turned into hardware by running it through synthesis on free-software.
The reason that I wish to stress this is because there are many ways to solve a problem. You will only be able to write code that solves it efficiently, from a gate count and timing stand point, if you understand how it gets translated into underlying hardware.
Good luck!
This is the book I used for Systems Architecture class. It is dirt simple.
Be carefull though things are not always parallel. Sequential assignments are different than combinational assignments.
I'm not sure what your background or needs are, but Digital Design and Computer Architecture, by David Harris and Sarah Harris, was a very useful introduction for me. It's not VHDL specific (Verilog and VHDL examples are presented side by side) or even HDL-heavy – as the title would suggest, it's more of an introduction to digital design in general. But for me it has been a great approach, presenting the code along with a grounding in its application and theoretical context.
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 10 years ago.
Somehow I've got the feeling that many projects become heavily overengineered so every possible change-request can be tackled with the effect that the change-requests that occured are very hard to implement.
Somehow I get that feeling in nearly every project I'm currently working on. It is like everyone is thinking "which cool api, framework, etc. can we add to the project to tackle this and that aspect" without evaluating if it is practical or needed.
Does anyone else feel the same or what's the opinion of the community here?
Yes.
-- MarkusQ
I find that, while some older companies with 'senior' senior management tend to be extremely rigid with how their business code is created, newer companies completely lack a backbone of what software they use to get the job done.
The problem you describe sounds like people are viewing problems at too high a level and want to find a way to solve it in one go. Creating a working toolbox (think standard libraries) would help them out in the long run.
I particularly enjoy the UNIX way of things: Several tiny utilities that do one thing and do it really well.
Definitely - I think people get 'robust and modular' and 'overengineered' mixed up far too often.
I think Dave Winer captured the cyclical nature of this phenomenon well:
The trick in each cycle is to fight
complexity, so the growth can keep
going. But you can't keep it out,
engineers like complexity, not just
because it provides them job security,
also because they really just like it.
But once the stack gets too arcane,
the next generation throws their hands
up and says "We're not going to deal
with that mess."
Guilty as charged. Three levels of abstraction and six config files is just more fun to implement than a simple flow control branch.
Overengineering is a danger in any project, large or small. When writing for code extensibility, there's always a trade-off between writing code that is sufficiently generic and extensible to allow for future development and code that is specific enough to make the task at hand easy.
Every "future hook" has a cost and should be evaluated in the light of that cost, the probability that it will ever be used, and the cost of refactoring later in the game. "More generic" is not always better.
As for using a hot, new framework or API, I think project managers should take a gentle hand in this. With development being such a fast-moving field, hands-on self-training is part of the price of doing business (but obviously should be kept reasonable.)
I've only encountered that with Java people: "Lets use spring!" And hibernate! I found this cool validation package as well! And this one will create XSLT to create XML forms to create the javascript!"
By the time I find all the jars and get them to play nice, there are dozens of classes I have to be familiar with. And then they want to abstract away all those pieces! "We might switch spring out. Or not use hibernate, so we should abstract those away". Add another dozen hacky wrapper classes.
By the time its all done, 50 lines of psuedo code has turned into several thousand lines of making the "cool stuff" work, and about 100 lines of business logic trapped within its hairy, hacky, bug-ridden hell.
I'm guilty of it myself, too, but thats only because I'm bored and have time to kill.
The key thing to keep in mind here is time. A "simple" project that is knocked out of the park on day one by an Excel spreadsheet or a web page can quickly expand in both its audience and scope to become an unsustainable monster.
Under-engineering is a danger, too. The world is full of "practical" people who will mock any efforts that are contrary to their opinion. Nobody remembers the person who disagreed a year later when the "simple" solution can't be sustained.
The trick is to balance the right degree of engineering and be able to adjust when things change.
I've been bitten a few too many times by applications that I've thrown together quickly which have subsequently become "critical" apps. Then I have to almost rewrite the darned thing. I just assume now that it will become critical and so I "write it right" the first time. Saves me time and effort in the long term. So oddly, it's about laziness.
Today's xkcd is the absolute truth:
I find that overengineering is a byproduct of boredom. I believe Jeff and Joel covered this in a podcast, but the idea is that coders who often overengineer may just be in a rut and need a change of pace (Jeff and Joel suggested that they be allowed to do different jobs like QA).
Yes. I think people nowadays think more about how something should be done, and whether "it's the right way ..." and so on, than just picking the simple solution which will equally get the job done. If you're not asked to expand it, then don't think about expanding it.
I think this is a problem, but not as big as it seems and that there are good reasons for it.
The problem is that most projects that are underengineered will die a quick death while the overengineered ones can survive. Thus, when you look at still living project, there is survivorship bias.
And, even if you are a good architect that aims for "just good enough", if in doubt you will use the more flexibe, scalable, ... (i.e., overengineered) solution. Because the failure mode if you do not meet the requirements (whatever they may be) is usually much worse than what happens if you exceed them.
I'm yet to work on any real world problem but I've read enough people blogging about this to assume there is a problem.
Absolutely. But it's not just developers, it's users too. "I want this and that and the other in order to improve communication and increase productivity!".
I'm amazed at how many of these types of projects we've solved by just putting a shared folder on a file server.
As others have said, I've had too many 'small' projects become big ones and the short cuts taken become paint.
There is a place for a quick-and-dirty solution and in trying to follow the YAGNI mantra, I've created simple apps with no engineering.
With that though, you are not going to be able to jump into a million line system and develop the 'well engineered' system without practice on smaller systems.
I've taken to always following the developed architecture of our company in all projects because it helps me to work out solutions in line with the engineering principles we are trying to follow.
What you practice, you perform, so always do your best.