The ternary conditional operator (?:) can be used as a short-hand version of an if statement. It is a feature of many languages.
For example, this code:
int height; if(isTall) height = 50; else height = 10;
can be better written as:
int height = isTall ? 50 : 10;
The ?: operator is good for replacing very simple if statements, but is bad for complicated if statements as it can harm readability.
Here is a common misconception when it comes to password security:
“It’s unsafe store user passwords as plain text in the database, so I’ll MD5 the passwords. MD5 is safe because it is one-way encryption, and takes too long to brute force.”
WRONG!
An unsalted MD5 hash can be cracked in less than a second, because it is vulnerable to a precomputation attack. Don’t believe me? Try it for yourself. There are dozens of websites that will take a hash, and return the original password almost instantly. This is true of all hashing algorithms, not just MD5.
How do you defend against a precomputation attack? You use a salt when computing the hash. Using a large salt makes it infeasible to precompute. Also, it helps if you have a strong password that contains numbers, uppercase letters, lowercase letters, and especially symbols. You get bonus points if your password contains strange characters (unicode characters, ascii characters above 128, etc) because nobody can be bothered precomputing rainbow tables for those.
This post is the result of investigation into a stackoverflow.com question of mine.
So, you’ve created a spiffy NSView of your own, and have decided to make it compatible with bindings. Great! So you go and read the documentation, and you look at mmalc’s GraphicsBindings example. You override bind:toObject:withKeyPath:options: and everything works. But wait! Why isn’t the NSWindowController ever being deallocated anymore?
Now you’ve got a nasty retain cycle on your hands. You do a little research and discover that not only do other people have the same problem, but even Apple’s bindings used to have it a few years ago. How did Apple fix the problem? With the magic, undocumented class NSAutounbinder, which nobody seems to know much about.
Other people will tell you that you don’t need to override bind:toObject:withKeyPath:options: and that bindings work automatically. This is only a half truth. NSObject does provide an implementation of bind:toObject:withKeyPath:options:, but it only half works. Using the default NSObject implementation, changes in the model will update the view, but the reverse is not true. When the bound property of the view changes, nothing happens to the model.
So, what is a Cocoa developer to do? I’ll explain how to implement your own bindings that work exactly like Apple’s, with no retain cycles. I haven’t found this solution anywhere else, so as far as I know, I’m the discoverer. I feel so special. It has been mentioned before at least once. The solution is hard to find, though.
Can you tell what is wrong with the abstraction in this class interface?
@interface EmployeeList -(void) addObject:(Employee*)anEmployee; -(void) removeObject:(Employee*)anEmployee; -(NSUInteger) numberOfEmployees; @end
Here is the answer:
Read the rest of this entry »
Having one exit point (return) from a function is a good thing. Here is an example of a single exit point:
int MyArray::indexOfElement(int elementToFind){ int foundIndex = ELEMENT_NOT_FOUND; for(int i = 0; i < m_numberOfElements; ++i){ if(this->elementAtIndex(i) == elementToFind){ foundIndex = i; break; } } return foundIndex; }
Having multiple exit points can be bad. Here is an example of multiple exit points:
int MyArray::indexOfElement(int elementToFind){ for(int i = 0; i < m_numberOfElements; ++i){ if(this->elementAtIndex(i) == elementToFind){ return i; } } return ELEMENT_NOT_FOUND; }
Why are multiple exit points bad? Because I say so. They are also bad for these two reasons:
The previous article, Model View Controller Explained, explained what MVC is and why it’s such a good design pattern. The model view controller design pattern has a flow. Actions flow from the view to the model via certain pathways. Conversely, changes to the model flow through to the view. This article will dive into finer detail about these pathways, and discuss some of the specific mechanisms and design patterns used to implement the flows.
Read the rest of this entry »
Model view controller (MVC) is a very useful and popular design pattern. If you’re writing software, you should know it. Unfortunately it’s also one of the hardest to truly understand. In this article I will provide what I think is the simplest explanation of MVC, and why you should use it.
Read the rest of this entry »
