Open Side Menu Go to the Top
Register
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** ** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD **

02-26-2014 , 09:43 PM
so for full comp:

JS:
Code:
eachSlice(_.shuffle(_.range(arraySize)), groupSize);
Ruby:
Code:
(1..25).to_a.shuffle.each_slice(5).to_a
http://jsfiddle.net/Pj5mL/1/
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
02-26-2014 , 10:11 PM
The funny thing to me now is the JS version has so many parens that it might as well be scheme compared to the ruby version.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
02-26-2014 , 10:19 PM
yeah, uglier for sure. you can get around that if you're willing to monkeypatch Array.prototype
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
02-26-2014 , 11:53 PM
So I dont know design patterns (Im working on it I swear), and one of the issues I frequently have in the real world is coming up with nice ways to change functionality for a method that is used 100 times in a large enterprise app. The following is a pretty simplified example, if anyone has any input.

Basically we have a list of objects, well call it decisionList. We iterate over decisionList, and for each object in that list, we decide whether the object will be updated, or deleted.

Code:
for( int i = 0; i < decisionList.size(); i++) {
	makeDecision(decisionList.get(i), theres, 9, params,
                            in, this, function, which, sucks);
}
..

private void makeDecision(Object obj , theres, 9, 
                              params, in, this, function, 
                              which, sucks) {
	if obj == blah {
		delete();
	} else {
		update();
	}
}
So basically, for each object in decisionList, it decides what to do with the items, and then performs the action immediately. Now I have to change it so the actual actions for delete and update happen after EVERY object in decisionList is sorted into their respective lists. So the simple (terrible?) solution is to add in 2 more lists as parameters, and add to that each time we make a decision with the objects. This of course changes the parameters of a method that is possibly used a ton of times, and that breaks the code in many places.

So I hope this wasnt too long or poorly explained. Like I said, its incredibly simplified, but the concept is similar. If anyone has any comments, Id love to hear them!
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
02-27-2014 , 12:09 AM
PJ,

A lot more context would be helpful. But yeah, if you are passing in 9 params to a method something is probably wrong.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
02-27-2014 , 12:24 AM
Quote:
Originally Posted by Shoe Lace
The funny thing to me now is the JS version has so many parens that it might as well be scheme compared to the ruby version.


I don't have a Scheme compiler these days, so:

Code:
(defn random-matrix [n r]
 (vec
   (for [x (range n)] 
     (vec (take n (repeatedly #(rand-int r)))))))
I think all the javascript answers have been given already.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
02-27-2014 , 12:42 AM
Quote:
Originally Posted by gaming_mouse
PJ,

A lot more context would be helpful. But yeah, if you are passing in 9 params to a method something is probably wrong.
Yeah, old ass enterprise code bases

The 9 params are already there in actuality, and I just included that fact to stress how much I hate just adding parameters to solve a problem. Its a simple quick solution that generally sucks for anyone coming in afterwards.

Im not really sure how to give a lot more context without actual code, and thats most certainly not allowed. Im just a new developer trying to figure out dealing with insane amounts of inheritance, and trying to not compound the problems of a large codebase. Life is hard!
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
02-27-2014 , 02:16 AM
Quote:
Originally Posted by candybar
Asymptotic here means ignoring constant factors and focusing on growth as input size gets large. For example, merge sort, at O(n log n) is said to be asymptotically faster than insertion sort at O(n^2) which means for any given input on any particular machine insertion sort may be faster than merge sort, but regardless of setup, once you get to a large enough input, merge sort is going to be always faster than insertion sort.

http://en.wikipedia.org/wiki/Analysis_of_algorithms

Amortized simply means analyzing time complexity over an entire sequence of operations.

http://en.wikipedia.org/wiki/Amortized_analysis

Naive is just something a reasonable person would first gravitate towards. In this case, a naive lazy/sparse solution would involve issuing random numbers to requests, keeping tracking of them (as keys in a sparse array or hash for fast lookup as well as values in a separate cache so that multiple requests would return the same value), and just retrying until you have unique number. This obviously runs into a problem at the end as it's going to take forever to issue the last few remaining random numbers.

http://stackoverflow.com/questions/2...lementation-is
You live in a whole different programming world than I do. I'm like the guy at NASA who makes sure the ship gets built properly, and you're the guy who designs the rocket.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
02-27-2014 , 09:34 AM
Quote:
Originally Posted by PJo336
So I dont know design patterns (Im working on it I swear), and one of the issues I frequently have in the real world is coming up with nice ways to change functionality for a method that is used 100 times in a large enterprise app. The following is a pretty simplified example, if anyone has any input.

Basically we have a list of objects, well call it decisionList. We iterate over decisionList, and for each object in that list, we decide whether the object will be updated, or deleted.

Code:
for( int i = 0; i < decisionList.size(); i++) {
	makeDecision(decisionList.get(i), theres, 9, params,
                            in, this, function, which, sucks);
}
..

private void makeDecision(Object obj , theres, 9, 
                              params, in, this, function, 
                              which, sucks) {
	if obj == blah {
		delete();
	} else {
		update();
	}
}
So basically, for each object in decisionList, it decides what to do with the items, and then performs the action immediately. Now I have to change it so the actual actions for delete and update happen after EVERY object in decisionList is sorted into their respective lists. So the simple (terrible?) solution is to add in 2 more lists as parameters, and add to that each time we make a decision with the objects. This of course changes the parameters of a method that is possibly used a ton of times, and that breaks the code in many places.

So I hope this wasnt too long or poorly explained. Like I said, its incredibly simplified, but the concept is similar. If anyone has any comments, Id love to hear them!
Who owns the list? Is the list manipulated by the 100 places that use the makeDecision function?

Why do you need 2 separate lists? Why not just use a flag on each object to indicate update/delete?

If you need to pass in 9 parameters it is almost certain those parameters should belong to the class that makes the decision. And if 9 parameters is really necessary at least package them into a lightweight structure (and initialize them once, when passing to the constructor of makeDecision's class).
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
02-27-2014 , 09:48 AM
Dave, nice one. That is readable too. Although when I looked at it all I could think of was professor Sussman closing all of the parens with his chalk from the SICP lecture videos.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
02-27-2014 , 10:14 AM
Quote:
Originally Posted by PJo336
So I dont know design patterns (Im working on it I swear), and one of the issues I frequently have in the real world is coming up with nice ways to change functionality for a method that is used 100 times in a large enterprise app. The following is a pretty simplified example, if anyone has any input.

Basically we have a list of objects, well call it decisionList. We iterate over decisionList, and for each object in that list, we decide whether the object will be updated, or deleted.

Code:
for( int i = 0; i < decisionList.size(); i++) {
	makeDecision(decisionList.get(i), theres, 9, params,
                            in, this, function, which, sucks);
}
..

private void makeDecision(Object obj , theres, 9, 
                              params, in, this, function, 
                              which, sucks) {
	if obj == blah {
		delete();
	} else {
		update();
	}
}
So basically, for each object in decisionList, it decides what to do with the items, and then performs the action immediately. Now I have to change it so the actual actions for delete and update happen after EVERY object in decisionList is sorted into their respective lists. So the simple (terrible?) solution is to add in 2 more lists as parameters, and add to that each time we make a decision with the objects. This of course changes the parameters of a method that is possibly used a ton of times, and that breaks the code in many places.

So I hope this wasnt too long or poorly explained. Like I said, its incredibly simplified, but the concept is similar. If anyone has any comments, Id love to hear them!
Good post. People run up against these kinds of problems a lot in the development world. I don't have a simple answer but I'll offer a few comments.

You could use an overloaded method I'm guessing.

There is a balancing act between how much you revise (refactor) legacy code and the risk you take in breaking (introducing defects into) the existing code base. Code reviews should be your friend here.

Introducing a new design pattern into a legacy code base is part of the balancing act.

Btw I've never been asked in an interview about how I approach these kinds of issues. Could be because I bring up the issue first but it seems kind of important.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
02-27-2014 , 10:37 AM
Quote:
Originally Posted by suzzer99
You live in a whole different programming world than I do. I'm like the guy at NASA who makes sure the ship gets built properly, and you're the guy who designs the rocket.
Meh, I'm just a math/CS-theory nerd and we do pretty much the same thing - these kinds of things come up like once every few months though I do get bothered when, for instance, backend guys with 10+ years of experience working with relational databases and no other expertise have no idea how indexes, caching, query plans, etc work at the database layer. Other than adding to my stress level throughout the day and probably slowing me down some because I overthink, my disposition is mostly useful for interviewing fresh CS grads or people with advanced degrees.

I may very well be a better fit for more theory-heavy jobs than pure application development, whether research labs or even frameworks and lower-level stuff but I'd have to take a large pay cut, which is tough to stomach with a family, mortgage and such.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
02-27-2014 , 10:39 AM
Quote:
Originally Posted by PJo336
So I dont know design patterns (Im working on it I swear), and one of the issues I frequently have in the real world is coming up with nice ways to change functionality for a method that is used 100 times in a large enterprise app. The following is a pretty simplified example, if anyone has any input.

Basically we have a list of objects, well call it decisionList. We iterate over decisionList, and for each object in that list, we decide whether the object will be updated, or deleted.

Code:
for( int i = 0; i < decisionList.size(); i++) {
	makeDecision(decisionList.get(i), theres, 9, params,
                            in, this, function, which, sucks);
}
..

private void makeDecision(Object obj , theres, 9, 
                              params, in, this, function, 
                              which, sucks) {
	if obj == blah {
		delete();
	} else {
		update();
	}
}
So basically, for each object in decisionList, it decides what to do with the items, and then performs the action immediately. Now I have to change it so the actual actions for delete and update happen after EVERY object in decisionList is sorted into their respective lists. So the simple (terrible?) solution is to add in 2 more lists as parameters, and add to that each time we make a decision with the objects. This of course changes the parameters of a method that is possibly used a ton of times, and that breaks the code in many places.

So I hope this wasnt too long or poorly explained. Like I said, its incredibly simplified, but the concept is similar. If anyone has any comments, Id love to hear them!
I don't understand why you have to change that method at all. Can't you just sort outside of it before? Don't cram too much functionality into one function.

Edit: oh wait, do you need to get a list of updated objects and a list of "deleted" objects?
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
02-27-2014 , 10:39 AM
Quote:
Originally Posted by PJo336
So I dont know design patterns (Im working on it I swear), and one of the issues I frequently have in the real world is coming up with nice ways to change functionality for a method that is used 100 times in a large enterprise app. The following is a pretty simplified example, if anyone has any input.

Basically we have a list of objects, well call it decisionList. We iterate over decisionList, and for each object in that list, we decide whether the object will be updated, or deleted.

Code:
for( int i = 0; i < decisionList.size(); i++) {
	makeDecision(decisionList.get(i), theres, 9, params,
                            in, this, function, which, sucks);
}
..

private void makeDecision(Object obj , theres, 9, 
                              params, in, this, function, 
                              which, sucks) {
	if obj == blah {
		delete();
	} else {
		update();
	}
}
So basically, for each object in decisionList, it decides what to do with the items, and then performs the action immediately. Now I have to change it so the actual actions for delete and update happen after EVERY object in decisionList is sorted into their respective lists. So the simple (terrible?) solution is to add in 2 more lists as parameters, and add to that each time we make a decision with the objects. This of course changes the parameters of a method that is possibly used a ton of times, and that breaks the code in many places.

So I hope this wasnt too long or poorly explained. Like I said, its incredibly simplified, but the concept is similar. If anyone has any comments, Id love to hear them!
I'm still not sure if I understand your problem correctly, but as I understand it I think I would do something like:

Code:
private void deleteOrUpdateList(decisionList, ...) {
  toDeleteList = new List()
  toUpdateList = new List()

  for( int i = 0; i < decisionList.size(); i++) {
    obj = decisionList.get(i)
    if (shouldBeDeleted(obj,...)) {
      toDeleteList.append(obj)
    } else {
      toUpdateList.append(obj)
    }
  }
  //Go through and call your delete/update methods
}

private bool shouldBeDeleted(Object obj, ...) {
   return <delete check>;
}
Then test your methods.

Hard to know if this is the right thing without context, but the important thing is to make the thing you have to change better and well tested, but try to avoid changing things outside of what you're doing.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
02-27-2014 , 10:44 AM
Quote:
Originally Posted by jjshabado
I'm still not sure if I understand your problem correctly, but as I understand it I think I would do something like:

Code:
private void deleteOrUpdateList(decisionList, ...) {
  toDeleteList = new List()
  toUpdateList = new List()

  for( int i = 0; i < decisionList.size(); i++) {
    obj = decisionList.get(i)
    if (shouldBeDeleted(obj,...)) {
      toDeleteList.append(obj)
    } else {
      toUpdateList.append(obj)
    }
  }
  //Go through and call your delete/update methods
}

private bool shouldBeDeleted(Object obj, ...) {
   return <delete check>;
}
Then test your methods.

Hard to know if this is the right thing without context, but the important thing is to make the thing you have to change better and well tested, but try to avoid changing things outside of what you're doing.
This looks like a good answer, you should even be able to keep makeDecision implementation - just refactor it to use shouldBeDeleted.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
02-27-2014 , 10:56 AM
Quote:
Originally Posted by candybar
which is tough to stomach with a family, mortgage and such.
literally. such a cut would surely eat into your bulk candy stipend...
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
02-27-2014 , 11:00 AM
Quote:
Originally Posted by candybar
This looks like a good answer, you should even be able to keep makeDecision implementation - just refactor it to use shouldBeDeleted.
If I understand correctly, his makeDecision implementation needs to change because he wants all the updates/deletes done at the end instead of immediately after each decision is made.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
02-27-2014 , 11:07 AM
This is probably a good time to point out some good* naming conventions:

- In a language like Java don't put the data type in the name. I'll be able to see that something is a list easily almost anywhere I'll care.
- Be specific. "makeDecision" doesn't tell me anything and I need to look at the implementation to see what's actually being decided. "shouldBeDeleted" is clear what the decision is and wherever its called I have a good sense of what's happening.
- methods should describe what they're doing and variables should describe what they are. "decisionList" doesn't give me any clue of what it is. "shoppingCartItems" does.


* Ruled good by me. I'm sure opinions differ.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
02-27-2014 , 11:15 AM
it would be hard to argue that those suggestions aren't good
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
02-27-2014 , 11:58 AM
Quote:
Originally Posted by candybar
Meh, I'm just a math/CS-theory nerd and we do pretty much the same thing - these kinds of things come up like once every few months though I do get bothered when, for instance, backend guys with 10+ years of experience working with relational databases and no other expertise have no idea how indexes, caching, query plans, etc work at the database layer. Other than adding to my stress level throughout the day and probably slowing me down some because I overthink, my disposition is mostly useful for interviewing fresh CS grads or people with advanced degrees.

I may very well be a better fit for more theory-heavy jobs than pure application development, whether research labs or even frameworks and lower-level stuff but I'd have to take a large pay cut, which is tough to stomach with a family, mortgage and such.
Yeah I have a degree in physics, and other than a couple community college classes I'm self-taught at programming. So I definitely missed all the CS theory. I don't think it slows me down at my job – but I would like to know all that stuff.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
02-27-2014 , 12:24 PM
Quote:
Originally Posted by jjshabado
I'm still not sure if I understand your problem correctly, but as I understand it I think I would do something like:

Code:
private void deleteOrUpdateList(decisionList, ...) {
  toDeleteList = new List()
  toUpdateList = new List()

  for( int i = 0; i < decisionList.size(); i++) {
    obj = decisionList.get(i)
    if (shouldBeDeleted(obj,...)) {
      toDeleteList.append(obj)
    } else {
      toUpdateList.append(obj)
    }
  }
  //Go through and call your delete/update methods
}

private bool shouldBeDeleted(Object obj, ...) {
   return <delete check>;
}
Then test your methods.

Hard to know if this is the right thing without context, but the important thing is to make the thing you have to change better and well tested, but try to avoid changing things outside of what you're doing.
So if I'm understanding right, I should be making an entirely new method (in this case deleteOrUpdateList() rather than trying to alter the one it's currently using. That makes a lot of sense and I'm struggling with why I wouldn't think of that in the first place haha.

I believe for how poorly I described it, you do all get it, yes we need the full list of objects to be deleted before we delete anything.

I can't say I disagree with your rules of naming conventions in programming, but In a quick and dirty writeup of something in a forum post I think clarifying it's a list is fine.

My least favorite thing in legacy code is the piss poor comments. I'll come to a class written 5 years ago by someone who isn't here called AttrBasicHerpDerp and the comment will be "this is a class for AttrBasicHerpDerp" thanks guise!
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
02-27-2014 , 12:39 PM
Quote:
Originally Posted by PJo336
So if I'm understanding right, I should be making an entirely new method (in this case deleteOrUpdateList() rather than trying to alter the one it's currently using.
It depends. If there's still a use for the current method, then I'd probably rename it to something describing what its doing (referring to immediate execution of the operations). If there's no use for the current method and everyone should use your new method, I'd delete the old one. Deleting code is good!

Quote:
Originally Posted by PJo336
I can't say I disagree with your rules of naming conventions in programming, but In a quick and dirty writeup of something in a forum post I think clarifying it's a list is fine.
Yeah, I totally understand.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
02-27-2014 , 12:52 PM
Quote:
Originally Posted by jjshabado
Deleting code is good!
But I'm scared!
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
02-27-2014 , 01:26 PM
Quote:
Originally Posted by PJo336
But I'm scared!
That's what source control is for. To make it so that deleting code can never go too wrong.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
02-27-2014 , 02:39 PM
Quote:
Originally Posted by PJo336
But I'm scared!
Source control and unit tests. If you're doing a big refactor, write some new tests that tests those functions before refactoring. Removing code is always good. Code maintenance is generally much more expensive than code development -> less code is always better from business perspective.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote

      
m