Comment Re:What about home users? (Score 1) 70
Comment Re:On Wednesday (Score 1) 126
Comment Also... (Score 1) 86
Comment Pics or it didnâ(TM)t happen. (Score 1) 192
Comment Re:Comic book movies are no longer for kids (Score 1) 93
I think the difference is that the source material in Sin City was also for adults. With the exception of quasi-canonical stuff like the Injustice games, ZSJL is much more violent than most of the original source material.
Comment oh. Wait, what? (Score 3, Insightful) 164
"Sadly Rails documentation doesn't warn you about this pitfall, but if you know anything at all about using SQL databases in web applications, you'd have heard of SQL injection, and it's not hard to come across warnings that find_by_sql method is not safe," Dmitry Borodaenko, a former production engineer at Facebook who brought the commit to my attention wrote in an email. "It is not 100% confirmed that this is the vulnerability that was used in the Gab data breach, but it definitely could have been, and this code change is reverted in the most recent commit that was present in their GitLab repository before they took it offline." Ironically, Fosco in 2012 warned fellow programmers to use parameterized queries to prevent SQL injection vulnerabilities.
So, this was the vulnerability, unless maybe it wasn't the vulnerability, because we don't know.
Also, Rails documentation absolutely does warn you about the ">pitfalls of using find_by_sql indiscriminately:
Ruby on Rails has a built-in filter for special SQL characters, which will escape ' , " , NULL character, and line breaks. Using Model.find(id) or Model.find_by_some thing(something) automatically applies this countermeasure. But in SQL fragments, especially in conditions fragments (where("...")), the connection.execute() or Model.find_by_sql() methods, it has to be applied manually.
Comment Re:My customers insisted on monthly payments (Score 1) 356
Comment Not Here (Score 1) 698
Comment 200 countries, 200 gps clones? (Score 1) 210
Seems a bit of a waste for each country to get their own gps system. There are about 200 countries. How many systems do we really need? One.
How hard can it be? Just make one international system, that simply sends out the highest precision signal, all the time - no signal degradation options whatsoever.
Comment Re:You'll get this 2014 MBP (Score 1) 114
Comment Battery Drain? (Score 3, Interesting) 129
Comment Re:Translation : Amazon doesn't want to pay delive (Score 1) 222
Comment Re:Both wrong (Score 5, Insightful) 84
Comment Re:ObjC to Swift, 4 years in (Score 1) 262
This.
HUGE fan of Objective-C, back from the NeXT days. Been writing iOS apps since ARC was optional and I never used it, because *I* knew how to alloc and free memory. Yeah, that meant it was a pain in the ass when Apple made ARC a requirement.
I miss introspection, sure. But optionals, tuples, native unicode support, default parameters, conditional generics, and a consistent calling syntax just makes my life easier. Add to that first-class immutable structs, better functional programming support, and stronger exception handling, and I just enjoy programming Swift more than Objective-C.
It's not like dynamic dispatch went away -- it just got shuffled to object extensions.
That said, there are some things I don't like about Swift: lack of introspection (as I admitted), and especially still using ARC for memory management. While it may be fast, resolving retention cycles can be difficult, especially if one half of the retention is in some Cocoa library.
Swift doesn't lock you into Apple products. It's an open-source language, for cryin' out loud. What locks you into Apple products are the libraries you use to target a specific platform. Just like MFC locks you into Microsoft products.
I can see why some people might prefer Objective-C. I still look on it fondly as the best of the C-based OO languages. Hell, I still love programming in straight-up C.
I'm just glad I made the jump to Swift.
Oh, I'm also moving to Kotlin for my Android projects for many of the same reasons.