Tag Info

Hot answers tagged

31

There is a third option ... write clean code via test driven development to implement the requirements that are needed today because YAGNI. The temptation to write code that isn't necessary at the moment but might be in the future suffers from several disadvantages ... from You ain't gonna need it: The time spent is taken from adding, testing or ...


25

Use a tool like Microsoft SketchFlow, or make your prototype in some other language or platform, making it nearly impossible to integrate into main development. There's also a joelonsoftware essay about showing screenshots and prototypes, where he makes unimplemented and unworked aspects appear obviously broken/unimplemented, making it clear where work ...


25

Using C doesn't automatically make your application faster. When you have the ability to choose a different programming language for your platform I highly recommend it. As Bill Harlan stated: It is easier to optimize correct code than to correct optimized code. Premature optimization actually hinders optimization in the long run. Unnecessary ...


13

That's not how the prototype works. The prototype is used in the prototype chain. Whenever you try to get a property on an object it will check the object for that property name. If it does not exist it will look in the prototype. Example: var o = { "foo": "bar", "method": function() { ... } }; var o2 = Object.create(o); var o3 = Object.create(o); ...


12

Don't prototype with working code. Prototype with pencil and paper, or a software equivalent. Using Mockups feels like drawing, but because it’s digital, you can tweak and rearrange easily. Teams can come up with a design and iterate over it in real-time in the course of a meeting. Using paper has the benefit that team members can easily jump in, and ...


12

I prefer a whiteboard. It makes it easy to change as you make decisions without redrawing the whole thing. It's easy to share with other (nearby) developers. It's easy to annotate using sticky-notes or other colors.


12

as usual... It Depends If you are prototyping to mitigate a risk or expose an unknown, just code it and expect to throw it away when you're done If you are prototyping for iterative refinement, just code it and expect to modify and refactor it frequently If you are starting to write the actual product but calling it prototyping so you can be lazy, then ...


12

Bubbling is an event flow mechanism in the DOM where events that are designated as "bubbling" (such as your click event), after being dispatched to their target, follow the target's parent chain upwards, checking for and triggering any event listeners registered on each successive target. In other words, given a DOM like this: <div id="foo"> ...


12

But it seems like they are avoided for the creation of executable applications and of bigger projects in general. Why that? I don't know, but the assumption is false. Larger projects use prototypical languages: JavaScript is the most popular language on github. Cloud9 is a full-blown cloud based IDE written in JavaScript that connects to GitHub. 98% ...


12

The "correct" answer is yes. TDD should be considered "best practice" wherever the tools for TDD are available either in the language or in the framework. Even if they aren't available in a form you may be used to with Java or .NET, you can create a simple program that consists of calling each of the unit test methods one at a time, catching thrown ...


12

The technical term for a class with a pure virtual function is abstract class, but that terms also applies if the class has additional non-pure virtual functions. Often the term Interface is used in C++ to describe an abstract class like Printable, that describes a service that can be provided by a range of different, otherwise unrelated classes. This ...


11

Stick to the Python. It has all the values, it just works and you already know it. If you're having doubts read this: http://www.scientificcomputing.com/High-Performance-Development-with-Python.aspx - very good article covering prototyping in python.


9

Classical inheritance inherits the behavior, without any state, from the parent class. It inherits the behavior at the moment the object is instantiated. Prototypal inheritance inherits behavior and state from the parent object. It inherits the behavior and state at the moment the object is called. When the parent object changes at run-time, the state and ...


8

I'm going to side with Paul Graham on this one: dynamic typing is most useful for creating programs organically, which is exactly what prototyping ought to be. The point is to get something done quickly that demonstrates the functionality of the final product, not the final product itself. Static typing is about formal correctness—well, ostensibly; at least ...


7

Balsamiq mockups are usually the first port of call, almost as quick as using a pen and paper and reusable. Plus you can add some degree of interactivity if you wish, linking pages together for example. http://balsamiq.com/


7

Personally I would worry about hiring someone who spent their time doing proof of concept stuff because it sounds like they are trained to get stuff working in a very beta/high level way but maybe couldn't deal with the real fiddly bits of actual implementation. That being said if the work was there it would be a wicked awesome job.


7

Ask potential users to test it. If there are no potential users, or you have no idea how to reach them, the idea is basically worthless.


7

It would not be valuable to do that, because a) the parts of those languages that translate directly to C would not be any simpler, and b) the parts that don't translate directly to C would be more difficult to rewrite in C than if you'd written them in C in the first place.


7

When you did fred.salary=20000 you have added the salary attribute only to fred. When using prototype, all employees you will create from then on will have the salary attribute. Say you have 100 instances of employees, and you wanted to add a salary attribute to all of them. You could to it manually, iterate over each employee and add it. Or you could use ...


7

Your own sequence and class diagrams probably do not depend that much on how the graphics engine behaves. During implementation, you will probably run into little quirks like 'I must call initFoo() before setupBar()' but those details most likely do not affect the design of your classes. Your tech-lead needs your design now, probably because other people ...


7

Gather better, more specific customer requirements. When you refine the requirements to the point where each requirement can be satisfied with a handful of classes, and you have a pretty good idea what those classes will look like in code, it will become much clearer how long things are going to take, and it will be much easier to declare success on each ...


7

Isn't rapid prototyping (i.e. iterative and incremental development) sort of the whole point of Agile? It sounds like you're having issues with "perception is reality" at your organization. You might want to remind everyone that Agile doesn't mean "throw out all plans," any more than Test-Driven Development means "throw out all architecture." And Python ...


6

If you are prototyping, why are you thinking about clean code? The very idea of prototyping is that it's meant to prove a concept or idea, and to be thrown away afterwards. I'm going to disagree with most everyone here by saying that if you are already thinking about the choice between writing clean code or getting something done quickly for prototyping, ...


6

Being fast to type is one positive. Being fast to type yet easy to spot is even better -- and people tend to spot dollar signs in walls of text relatively quickly.


6

Recent blog post about JS OO I believe what your comparing is classical OO emulation in JavaScript and classical OO and of course you can't see any difference. Disclaimer: replace all references to "prototypal OO" with "prototypal OO in JavaScript". I don't know the specifics of Self or any other implementation. However prototypal OO is different. With ...


6

First: Most of the time, you'll be using objects, not defining them, and using objects is the same under both paradigms. Second: Most prototypal environments use the same kind of division as class based environments -- mutable data on the instance, with methods inherited. So there's very little difference again. (See my answer to this stack overflow ...


6

I think the static vs. dynamic type issue isn't as important as many people make it out to be. I use both. Sometimes one is simply more useful than another in a given situation. This is most often caused by needing to use some specific tool/library/technology. So I chose what works well with the other components I have. I think that one of the things that ...


6

The Guide to the Software Engineering Body of Knowledge describes prototyping as a method of requirements validation as well as requirements elicitation in Chapter 2, Section 6, Subsection 2: Prototyping is commonly a means for validating the software engineer's interpretation of the software requirements, as well as for eliciting new requirements. ...


6

How can be inherited an object? function inherit(o){ // inherit is called Object.create in modern implementations var F= function(){}; F.prototype=o; return new F(); } var parent = { name: "Josh", print: function(){ console.log("Hello, "+this.name); } }; parent.print(); // Hello, Josh var child = inherit(parent); ...



Only top voted, non community-wiki answers of a minimum length are eligible