Win a copy of Svelte and Sapper in Action this week in the JavaScript forum!

Monica Shiralkar

Ranch Hand
+ Follow
since Jul 07, 2012
Cows and Likes
Cows
Total received
9
In last 30 days
1
Total given
0
Likes
Total received
20
Received in last 30 days
2
Total given
132
Given in last 30 days
22
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Monica Shiralkar

Junilu Lacar wrote: I prefer focusing on interesting behavior.



Thanks. All I could think about while thinking about the behaviour to target upon in step 1(think about a little bit of functionality I want the program to have), is some functionality which even small would get a flow working such that later one can target on adding full features and refactoring. In that context ,what is meant by "intresting behaviour".Does it mean "core behaviour"?
34 minutes ago

Junilu Lacar wrote:I suggest you try it out yourself. You don't learn how to swim by listening to someone explain how they do it or reading about how someone trains for a swim meet. You learn to swim by getting in the pool and actually trying to do it.



Thanks.I will surely do that. Also ,if I take the example of online Shopping Application, I can think of simplest flow as list some items on the front end.

To quickly come up with this , instead of putting in the database ,initially I will set some data in a list in the Model and show using it.

I would park other work for later such as putting this in the database and making the controller call an API to return this and adding other features.

It seems, I got the answer. The aim has to be to think of a quick flow one can get running and then build/refractor.
2 hours ago

Junilu Lacar wrote:.

Basically, my development loop is this:
1. Think about a little bit of functionality I want the program to have
2. Write a small test that, when it passes, demonstrates that the program has that little bit of functionality. See the test fail.
3. Write a little bit of code to make the test pass.
4. Refactor the code to eliminate duplication and make the intent of the code clear. Simplify the code as much as I can.
5. Run the tests again to make sure nothing got broken.

This loop is between 2-5 minutes long if I have a good overall idea of what I want the program to do. It can go longer, sometimes up to 15 minutes, if it's a difficult problem that I haven't found a way to break down into smaller problems yet. Typically, however, that loop is less than 10 minutes long. This means I'm constantly experimenting with different options and constantly reorganizing code, renaming things, moving things around, deleting things, adding things. My code is hardly ever "done" until I'm all out of ideas for how to test the program and how to make it easier to read and work with.



All I want is to learn how to use this way with an example ( which can be any common example say a shopping cart application or online banking application or Notification Engine or any common application ).So that I can try using this way in the next requirement I work on.
16 hours ago
And what would be that for example if you are to build an online shopping application.What would be the loop that would take less than 10 minutes ?
17 hours ago

Junilu Lacar wrote:

Monica Shiralkar wrote:i think that would  mean that for example one may initially hard code any values required ,get the flow working and later on remove the hard coding by reading  from config file.


That is quite a leap of reasoning you're making there. What you describe is not an unreasonable approach but "thinking about some piece of functionality I want to implement" does not in any way imply what you describe as a specific strategy. It seems like you're reading way too much into my statement than I intended to communicate.




From what I understood from "little bit of functionality I want the program to have ", is getting a flow working end to end .That is to say, not with all the functionality but the bare minimum required to get an end to end flow working . Once ,that would then add other functionality and keep doing refactoring . Please correct me if I am wrong.
18 hours ago

Campbell Ritchie wrote:Since this is BJ, please explain how a happy path differs from the downhearted paths we see here so often.



Sorry,what is BJ and what does downhearted paths mean?
21 hours ago
Thanks.i think that would  mean that for example one may initially hard code any values required ,get the flow working and later on remove the hard coding by reading  from config file.
1 day ago

Junilu Lacar wrote:
Basically, my development loop is this:
1. Think about a little bit of functionality I want the program to have
2. Write a small test that, when it passes, demonstrates that the program has that little bit of functionality. See the test fail.
3. Write a little bit of code to make the test pass.
4. Refactor the code to eliminate duplication and make the intent of the code clear. Simplify the code as much as I can.
5. Run the tests again to make sure nothing got broken.

.



Does this step 1 mean coming up with a Happy flow running ?
1 day ago

Tim Moores wrote:No. Just because client code doesn't know specifics of a called method does not mean the code complexity is reduced.



But doesn't abstraction reduce the complexity of design too (apart from the advantage that caller doesn't have to bother about change in implementation later on) ?
1 day ago


From what I understood:

Polymorphism :  one type can show different behaviour based on situation (what is refers).
Abstraction : the called does not need to bother about the details of implementation. (For e.g Interface type referring to either of its implementation types)

Advantage of abstraction/polymorphism : tomorrow if the implementation changes it does not bother the caller to do any changes.

(although both are not mutually exclusive).
2 days ago

Junilu Lacar wrote:It's all a matter of perspective. The externally observable behavior or result of different List implementations will be the same. This is in keeping with the Liskov Substitution Principle. However, internally, the implementations do in fact behave differently since they are after all implemented differently.

If you consider the example of engines, at some level a diesel engine essentially does the same thing a gasoline engine does: it provides power to drive the wheels of a vehicle. However, internally, diesel engines and gasoline engines operate in completely different ways. The same thing goes for ArrayLists and LinkedLists and any other implementation of the List interface.



Thanks.
Exactly. That was the mistake I was doing. I was thinking that adding to list (linkedlist/arrayList) is same behaviour. But internally it is different behaviour. Thus it goes with the meaning of polymorphism which means same types shows different behaviour depending upon situation.
2 days ago

Junilu Lacar wrote:ArrayList and LinkedList provide different implementations of the same behavior defined by List. That's the polymorphism part.



Thanks. I was thinking it is different behaviour (instead of different implementations) that means polymorphism. So was thinking that when the caller calls add method on list he sees the same behaviour (irrespective of whether it is arrayList or LinkedList.)..but as you said it is not about behaviour but about different implementations.

3 days ago
You had said it's a different type of abstraction. I understood. But my doubt is regarding polymorphism. (How is it a valid case of polymorphism when here behaviour is same instead of different ).
3 days ago