I have not written a lot of objective-c code and/or iOS code I can tell you though that temp non stack allocations create garbage. For example RHS of equal sign string allocations will create garbage.

say I have an object with an instance variable that is set in the constructor. I also have a method that is actually a bunch of calls to other methods with the end goal of altering the value of the instance variable. So now if I want to unit test one of these sub methods, I need to either set the instance variable (requiring an attr_accessor I wouldn't otherwise need) or have the function take an extra argument and set the actual instance variable to the return value elsewhere...

basically this,
as opposed to

I guess I never actually learned object oriented programming donking around in other languages... are you supposed to use instance variables like globals within a class?

Garbage collection is a dumb thing for a programmer to have to worry about on a modern well-powered device imo.

e i pi,

Your question truly cannot be answered without more information.

Some things of note, however:

1. If you're wanting to unit test private internal helper methods, something is wrong with your design. You should be unit testing the behavior of your objects. If you can't test everything you need that way, then your object design needs to change so you can.

2. Your second example wouldn't be safe in a multithreaded environment. That may or may not be relevant.

3. When you create instance variables for the *sole* purpose of avoiding parameters in methods, something has probably gone wrong, because such variables aren't really object "state." They're just temporary local variables that are needed during method execution, that you happened to put into instance variables to make things look prettier. You have put lipstick on a pig.

4. But really, the specifics of your problem matter.

Memory management on iOS has gotten a lot better. Pre-iOS 5.0, you had to manually manage your own memory. If you called alloc on an object, you had better call release on it when you're done with it, or else you'd be leaking memory. With iOS 5.0, they introduced ARC (Automatic Reference Counting), which at compile time would figure out where to slip invisible release calls into your code for you. That pretty much made memory leaks a thing of the past. It's actually not garbage collection since it happens at compile time and not run time, but I think the only real difference you have to worry about it is that retain cycles will leak memory. I don't really get EXC_BAD_ACCESS errors anymore except when it's my own fault, say I forget to create an object and pass it's initial nil value to something that can't deal with it.

Thanks, your reply helped a lot. I'm probably just writing more tests than I should be because I often just print out the return value of some helper while I'm writing it and then after making sure its right turn it into a test... I should probably stop that because it doesn't really add any value.

The instance variable is a hash of a bunch of types of hands with true/false values ie {quads: false, trips: false, over_pair: false etc... The whole class is a bit of a mess, its responsibility is to take a hash with the counts for each card in a hand ie KK776 would be {quads: [], trips: [], pairs: [K, 7], singles: [6]} and then use that in combination with the two card hand of a player to populate the hand value hash. So each method is checking for some conditions and manipulating the hand value hash, so the instance variable is kind of state... or maybe not, it's not its final state.

Maybe I just wrote it in a dumb way but I was having trouble thinking up an elegant way to write it because in my mind its just a long nested if else. I ended up with something like this but clearly I'm here asking,

looking through it now, it's even uglier than I remember. I have checks for things like 1 overcard, 2 overcards, differentiate between ace high with the ace on the board vs in the hand... junk that involves comparing the hand strength of all cards, just the flop and the two card hand.

I'm thinking maybe when I'm done with it I'll post all the code and see where I goofed (this is the first thing longer than 20 lines I've written in ruby so it's expected to be trash I think) This is the backend for the range evaluator I was working on in angular back in febuary btw. I got the parsing/formatting of "range strings" to work but it grew into a wild beast no doubt, im afraid to even look at it.

This sounds like a longer discussion, which I'd be happy to have if you post the full code at some point.

A couple more notes just on the above that may be helpful:

1. "The whole class is a bit of a mess, its responsibility is to take a hash with the counts for each card in a hand" -- This sentence was a warning sign to me. It suggests you're thinking about your object in terms of implementation (it takes a hash and does something) rather than in terms of its natural responsibility. It also suggest a gap between your natural way of thinking about the problem and your model of the problem in code. You want that gap to be as small as possible.

2. I think you may be shoehorning into a class a solution something that in your head is really just a bunch of individual functions. No need to do that. Ruby has modules and the "module_function" directive for creating utility functions. You shouldn't feel a need to create classes if that's not how you're thinking about your problem. The fact that you wanted to unit test each of the methods makes me think a collection of utility methods approach may be the right place to start. You can easily unit test each one, and unit tests would be appropriate for utility functions. Then later, you may (or may not) start to see the natural design, and want to start creating objects to simplify things and ease maintenance. Then again, it might not even be necessary. But right now, you don't seem to "see" your problem in terms of collaborating objects from your problem domain with discrete responsibilities. So no need to craft a solution that pretends you do.

cool I'll look into that. From the other class I intended to just instantiate the new object and right away grab the computed hash... so yea I guess that isn't really an object at all. Thanks!

Since you're prefixing all of your methods with "eval" it might be a good idea to wrap them in an Eval module and then shorten your method names so they don't all have "eval" in them.

Usually prefixing method names with something consistent is a sign that you want a module or class to wrap them in.

Yeah that's what I figured they'd do at some point. Good to know. I haven't done iOS apps in 3+ years.

Looking for some feedback on this session handling scheme:

We're using secure cookies for user login sessions. The encrypted cookies have the user's id and the time the session was created, and are created upon successful username/pass authentication. Nothing is stored on the server about the session.

The problem is that we want sessions to remain active for a very long time: we don't want to force logged in users to re-login. Whatever you may think of this security policy, it's a business decision that has been made and isn't changing. The problem occurs if the cookie itself is physically compromised (eg, a user's laptop or phone is stolen). The cookie remains valid and there is no way to stop it from being valid, other than to keep a list of "expired cookies" on the server. For example, we could have a table with two columns ("userid" and "expiration_date"), and any time a user manually logs out, or we log them out, and entry is made for that time, and any cookies created before the expiration_date are no longer valid.

What do you think of this strategy? Do you have any better alternatives?

Many very large and popular sites have infinite log in, but require a password auth when users do something that requires a monetary transaction or profile change (and not all the time either).

I can't remember the last time I logged into 2+2, HN, Amazon, eBay...

GM,

Couldn't you do something like have a last_login_at in the database, and on sign_in create that entry, then use that exact entry for the session information. Then when someone says they have had their information stolen, you can manually update that last_updated_at which would be verified against the session request, and invalidate the session?

I'm also a total rube when it comes to this stuff. Doesn't your server have some secret key that is used to encrypt/decrypt the cookies... so if you decrypt the cookie would it give you a user_id and last_login_at that you could verify match in the database?

yeah you could do that for sure. the advantage of my proposal is that i only need to store stuff on the server for users who have logged out, rather than all users (i could use redis for it). not a big deal since it's such a small amount of data, but that was my thought.

yeah that's how it works. it will work that way no matter what server side strategy i use.

Your idea seems pretty solid then, and is probably superior since less unused data is being stored for sure.

Yep

Yeah memory leaks are horribad. If the development environment handles memory allocation automatically it will handle garbage collection automatically it would seem. If objects are passed by reference then wouldn't the compiler complain about NULL references?

The compiler doesn't care, NULL/nil is just another value to it. Sometimes it triggers an assertion failure, for instance, trying to add nil to an array. Sometimes passing nil is exactly what you want, for example, a method might ask for a dictionary that holds a set of options, and if you pass in nil, it uses the default options. I shouldn't have said passing nil causes EXC_BAD_ACCESS, it causes assertion failures if you use it in the wrong place, which is fine and easy to debug. But, if you call a method on nil, it simply returns nil, it doesn't give you a bad access exception.

What I should have said is that the only time I now get EXC_BAD_ACCESS errors is when I pass an uninitialized variable to a method by mistake. That just happened a lot more pre-ARC when you had to handle your own release calls, it was a lot easier to over-release an object or forget to retain an autoreleased object and then try and use it later only to be told EXC_BAD_ACCESS with no other debugging information.

Interesting NULL references in C++ will generate a compile error.

Any thoughts on whether sites need a password confirmation field for registration?

I just noticed neither yahoo or twitter require one now. I guess if you mess up the password you can just reset it from your email.

With the rise in usage of password management software and password generators it starts to seem like more of a waste of time than it used to.

We just scrapped our confirmation field. It really is kind of pointless when you have a good email reset strategy.

Hey guys,

How does one go about handling events that cannot be accessed from the ribbon visual designer in visual studio? I know that I can generate event handlers for the ribbon controls in microsoft excel from the ribbon designer. How do I get event handlers that don't involve ribbon controls?

For example I would like to handle a mouse movement into the activesheet, or if a user switches between worksheets. How do I go about subscribing to these events? Is there any way to generate an event handler for these kinds of events (that don't involve controls in the ribbon) automatically in visual studio.

Ive spent quite a few hours trying to figure this out (I am new to VSTO and c#) with no luck.

Thanks a lot