If it’s been killing you like it’s been killing me and you want to enable key repeat in Lion just type the following in the command line:
defaults write -g ApplePressAndHoldEnabled -bool false
I couldn’t put up with it any longer.
I also added this user default to my list in a previous post: Mac OS X User Defaults. It contains a pretty thorough list of suggested and commonly sought changes.
I think one of the first questions all new iOS developers ask is “Why declare properties with attributes like (nonatomic, strong)?” This is especially true for those who learn iOS development through the Stanford Paul Hegarty iOS lectures.
Understanding properties in Objective-C and iOS can be tough the first go around. When I first started programming for iOS I didn’t really understand all the ins and outs of properties and I probably didn’t need to because I wasn’t writing complex applications.
Over the last 8 months I’ve done a fair amount of iOS programming and have run into a number of scenarios where I needed to create read-only properties and thread-safe objects/classes. Some times Stackoverflow.com just doesn’t cut it because there are so many different questions and accepted answers it’s hard to really tell when and why to code what. You always run the risk of just coding something that works, but not really understanding if it’s the best way or not. If you find yourself in this situation–wanting to better understand how to create a property with the right set of attributes (i.e. nonatomic vs atomic, etc.)–then the Programming for Objective-C guide for iOS is the right place to start.
I’d recommend against thinking you’re better off taking shortcuts by just digging around on Stackoverflow.com or random blog posts because reading documentation is boring and goes into unnecessary detail, especially if you want to grasp the fundamentals of when and why to code properties with specific attributes. The official documentation excels in this area because it provides the necessary level of detail with helpful examples. I’ve found it to be much more helpful in understanding the fundamentals of properties in iOS development. However, once you have read the documentation, the topics on Stackoverflow.com (and other sites) become much more meaningful and are very worthwhile.
Instead of paraphrasing the already concise documentation I’ll just summarize some of the key topics you can read about.** If you’ve been coding in Obj-C for a little while already I recommend jumping into the “Data Encapsulation” section of the Programming for Objective-C guide. This section discusses the following concepts:
readwrite, strong, atomic)readwrite vs readonlystrong vs weakatomic vs nonatomicunsafe_unretainedcopy__strong vs __weak__unsafe_unretainedIf you want further reading on variable qualifiers as it pertains to Automatic Reference Counting (ARC) then I recommend reading the Transitioning to ARC Release Notes. This documentation is quite insightful covers more on variable qualifiers in addition to two examples I found very helpful, namely an example of how the compiler interprets an implicit strong pointer to NSError and an example involving blocks and the __block qualifier.
**This begs the question “Why the blog post then if you aren’t feeding me any new information?” My goal is to provide a point of reference so that I and others will know where to look in the future. It’s not always easy to know where to look when there seems to be endless documentation on all possible subject matter. Furthermore, I’ve summarized the most important topics so I and others know whether that source will contain the information sought.
French author Antoine de Sanit-Exupéry said:
“In anything at all, perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away.”
Henry David Thoreau:
“Our life is frittered away by detail. Simplify, simplify, simplify! I say, let your affairs be as two or three, and not a hundred or a thousand; instead of a million count half a dozen, and keep your accounts on your thumb-nail.”
Simplicity is relevant to so many aspects of life, including design and development and living life in general.
The use cases are somewhat limited given the Google Chrome app is probably open all the time if you’re like me, but it is possible to use Spotlight to search Google and show the results in Chrome. All you have to do is adjust your Safari preferences appropriately. (If only it were this easy in iOS.)
Now launch Spotlight (Command + Spacebar), type in a search request and select “Search web for…“.
I’ve been doing a fair amount of research on software licenses, particularly free software and open source licenses, which I’ve learned are not the same and not to be confused. Up until now, I had heard a lot about open source, I had heard people argue about open source, I had used a lot of open source software and I had seen/used some free or open source code, including code that uses versions of the GPL, BSD, ASL and MIT software license. I can finally say I understand the differences. Feel free to correct me on any misunderstandings in the comments and I’ll do my best to make the necessary modifications.
DISCLAIMER: I am not a lawyer. I am not liable for any mistakes you make. This article does not guarantee a correct interpretation of the licenses discussed.
I think the most significant point to make about Free Software–and thus my first point–is that the word “free” refers to freedom and not price. The Free Software Foundation (FSF) is all about promoting and guaranteeing the freedom and rights of people to control and use technology how they want. Therefore, according to the GNU Project’s definition of free software, for software to be free it must guarantee four essential freedoms:
- The freedom to run the program, for any purpose (freedom 0).
- The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this.
- The freedom to redistribute copies so you can help your neighbor (freedom 2).
- The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.
In summary, ”users have the freedom to run, copy, distribute, study, change and improve the software.” This brings us to the most popular free software licenses: the General Public Licenses (v2 and v3) and the Apache License 2.0.
In essence, the GNU General Public License version 2 (GPLv2) guarantees end users the aforementioned rights–to use, copy, modify and redistribute GPL’d software. This idea is referred to as copyleft, which is nothing more than a play on the word copyright. Copyleft licenses inherently require that any derived works or modifications of the original software be distributed under the same license and that the terms of that license are preserved. As a result, once software–binaries and source code alike–is distributed under the GPL, any copy of that software must be redistributed with GPL, whether it has been modified or not. Copyleft requires that information necessary for reproducing and modifying the work must be made available to recipients AKA source code. A copy of the GPLv2 can be accessed from the GNU Project. Read section 3 for evidence of copyleft.
One final point about GPL is that GPL cannot be revoked from software once it has been distributed. The developer can, however, distribute their software under more than one license (separately) since they own the copyright.
In 2007, GPLv3 was published as a separate, new version. The major difference is a clause that discusses tivoization . According to GNU:
Tivoization means certain [computers]…contain GPL-covered software that you can’t effectively change, because the appliance shuts down if it detects modified software. The usual motive for tivoization is that the software has features the manufacturer knows people will want to change, and aims to stop people from changing them. The manufacturers of these computers take advantage of the freedom that free software provides, but they don’t let you do likewise.
In essence, GNU felt the license needed to be updated or modernized based on present-day practices that restrict users’ freedoms once they modify free software.
The Apache License 2.0 is authored by the Apache Software Foundation (ASF) and is the most current Apache license. Software licensed under AL 2.0 is also considered free software by the FSF.
You can still get a hold of versions 1.0 and 1.1 of the Apache License; however, the recommended version for distribution is 2.0, which is also designed to be more reusable. While the latest version might seem the obvious choice, that’s not always true. GPLv2 and GPLv3 are both current and may be used in different circumstances. Thus, GNU didn’t just update GPLv2 but created separate licenses. For example, the Linux kernel is still licensed under GPLv2 (GPLv2 is incompatible with GPLv3), while Apache updated all of its software from previous versions to AL 2.0. That said, most developers who opt for the GPL will use GPLv3 probably.
One of the most notable differences between AL 2.0 and the GPL licenses is that AL 2.0 is not copyleft; you do NOT have to distribute your source code upon request like you do under the GPL. You can keep them a secret if you like. Furthermore, AL 2.0 is not compatible with GPLv2, whereas AL 2.0 is compatible with GPLv3. However, this compatibility with GPLv3 is one way. To quote the ASF:
This licensing incompatibility applies only when some Apache project software becomes a derivative work of some GPLv3 software, because then the Apache software would have to be distributed under GPLv3. This would be incompatible with ASF’s requirement that all Apache software must be distributed under the Apache License 2.0.
Attribution is also a big part of the AL 2.0. As described in Section 4d, all attribution must be accounted for in a NOTICE file included with all distributions of the software.
One of the more common/popular software products that uses AL 2.0 is Google’s Android operating system. Google has explained why they use the AL 2.0 as opposed to other licenses, specifically the Lesser GPL (LPGL), which I’ve not discussed here. Another great article I encourage you to read that Google points users to is “Why Google Chose the Apache License 2.0 Over GPLv2 for Android” written by Paul Ryan on Ars Technica.
For a summary of Apache License, version 2.0 in layman’s terms, read the answer to the FAQ “I’m not a lawyer. What does it all MEAN?” from the Apache website.
If you’re like me, you’ve probably wondered if you can sell “free” software for money or if it’s legal to charge for software under GPL or ASL. The answer is YES.
While this might seem like a contradiction, it isn’t. Remember, the whole goal of free software is freedom and liberty. GNU actually encourages developers to sell software under the GPL. GNU argues that selling the software won’t make it any less free because anyone can redistribute that software for free.
For example, if I write a brilliant piece of software, license it with the GPL, decide to sell it for $300 and someone buys it, I cannot force them to resell it for $300 or even $1. That would infringe upon their rights. Furthermore, they can modify it, but it will still be under the GPL. They can even add code that isn’t under the GPL, but as long as that new code is compatible with the GPL, the combined software must be distributed under the GPL otherwise it cannot be distributed. To distribute the combined software without the GPL would be to violate the license. Once GPL, always GPL.
An important point to reiterate with GPL is that end users are entitled to the source code–not just the binaries or executable–under the GPL. This goes back to the concept of copyleft. That means you have to provide a way for the end user to download source code or something. From what I understand, you can charge for the source code, but under the “equivalent access” clause, you must charge no more than what you charged for the compiled software.
To use my previous example, if I charged $300 for my GPL’d software and the end user requests the source code, I am bound to provide them access somehow. Once again, as I understand it, I can charge them no more than the original $300 to access and copy ALL of the original source code. Without equivalent access, I would be able to charge them a zillion dollars, which would essentially limit their freedom of access. Copyleft does NOT apply to AL 2.0 as far as I’m aware.
For more information, read the actual terms of the GPL and ASL, or checkout this link to a set of questions from the GPL FAQ or this link to a section of the ASL FAQ.
The Open Source Initiative (OSI) is a non-profit corporation that advocates the benefits of open source, maintains the open source definition and provides a list of OSI approve licenses.
The open source definition enumerates 10 key points which I have summarized as follows:
Therefore, open source software (OSS) is “computer software with its source code made available and licensed with an open source license in which the copyright holder provides the rights to study, change and distribute the software to anyone and for any purpose” (Wikipedia).
The following are examples of OSI approved licenses:
BSD stands for Berkeley Software Distribution. One of the best ways to understand the BSD licenses is to just read them, or even just look at them. They are super short and easy to understand. Wikipedia provides a great overview where you can see the differences clearly. It’s mostly just the deletion or addition of a clause or two.
The Original BSD License, also known as BSD 4-Clause, contains 4 basic clauses and an “as is” liability clause. The 4 clauses are as follows:
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. All advertising materials mentioning features or use of this software must display the following acknowledgement: This product includes software developed by the [organization]. 4. Neither the name of the [organization] nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
The Revised BSD License is also known as the BSD 3-Clause. The only difference is that it removes the 3rd clause from the Original BSD License. Therefore, advertising materials do NOT have to display any acknowledgement of the software developer.
The Simplified BSD License is also known as the BSD 2-Clause or FreeBSD. The key difference is that it removes the 3rd clause from the Revised BSD License, which was the 4th clause of the Original BSD License, and basically states that. The Simplified BSD also adds the following statement at the end:
The views and conclusions contained in the software and documentation are those of the authors and should not be interpreted as representing official policies, either expressed or implied, of the FreeBSD Project.
The MIT License is the simplest and shortest of the licenses I’ve discussed.
Copyright (c) [year] [copyright holders] Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
In essence, the MIT License allows the end user to “use, copy, modify, merge, publish, distribute, sublicense, and/or sell” as long as the MIT License remains intact with all (re)distributions. The copyright holders are not liable for anything.
As you can tell, there is some overlap here between free software and open source. Historically, they have the same roots, but open source split off from free software, according to Richard Stallman. They overlap in what they advocate in a lot of ways, but use different terminology to describe what they advocate. As a result, interpretation may be different.
The major different, as far as I can tell, between free software and open source is mostly the premise each operates from. Free software is designed to protect the freedoms of the end user. But even free software licenses differ on their interpretation. The GPL is probably one of the more strict licenses since it requires distributors to provide access to the full source code. With regards to the comparison of free software and open source Richard Stallman, founder of the GNU Project, stated:
As far as we know, all existing free software would qualify as open source. Nearly all open source software is free software, but there are exceptions.
On the other hand, open source is about providing “open source” code and software.
In my opinion, the biggest difference(s) lie in the terms of each license. Read them carefully and seek legal counsel when necessary.
Hopefully that clarifies the difference. ;)
I haven’t really attempted to point out all the differences free software, open source and the various licenses that fall under each category. My biggest points were the general distinction between free software and open source, brief descriptions of the most popular licenses and whether or not you have to provide source code in distribution.
I encourage readers to explore the other terms of these licenses. Most require the terms of the existing license be distributed with any redistribution. Many require attribution of the original source developer. Attribution is usually a pretty big issue among developers and licenses and is something I have not thoroughly discussed here.
Licenses are often intimidating to read since they can be complex and confusing. However, if you’ve read this full article, I believe you could understand the gist of all aforementioned licenses in their original text. You’d probably understand what each clause has to say and would thereby profit from the actual terms and not what I’ve interpreted or summarized from my own research.
While this list may not be comprehensive, I think I’ve coeverd the major sources I’ve researched and referenced in my article:
http://www.fsf.org/about/
http://www.gnu.org/licenses/quick-guide-gplv3.html
http://www.gnu.org/licenses/rms-why-gplv3.html
http://www.gnu.org/licenses/gpl-faq.html#v2v3Compatibility
http://www.gnu.org/philosophy/free-sw.html
http://www.gnu.org/philosophy/selling.html
http://www.gnu.org/philosophy/pragmatic.html
http://www.gnu.org/philosophy/open-source-misses-the-point.html
https://en.wikipedia.org/wiki/Copyleft
http://en.wikipedia.org/wiki/Apache_License
https://www.apache.org/licenses/LICENSE-2.0.txt
http://www.apache.org/foundation/license-faq.html#WhatDoesItMEAN
http://www.apache.org/licenses/GPL-compatibility.html
http://arstechnica.com/uncategorized/2007/11/why-google-chose-the-apache-software-license-over-gplv2/
http://source.android.com/source/licenses.html
http://opensource.org/
http://en.wikipedia.org/wiki/BSD_licenses
http://en.wikipedia.org/wiki/MIT_License
http://opensource.org/licenses/MIT
I found a nice side-by-side file comparison plugin for Sublime called Glue Views. Something cool about Glue Views is that it supports more than two files at a time. The plugin’s developer has a number of other free packages available for Sublime, including similar diff tools.
On the Sublime feature request forum I noticed a number of folks want the developer to include diff-merge features in Sublime by default. I already use other diff-merge tools specifically for merging conflicts in Git and the like, so that’s not exactly what I was looking for when I found this plugin. For those looking for that kind of functionality, some forum posters have recommended using existing TextMate packages since they are supporter by Sublime without modification. If your interested in learning more, this thread is a good place to start.
To install Glue Views or other Sublime packages on a Mac (the process and location is similar on Windows), simply navigate to /Users/<user account>/Library/Application Support/Sublime Text 2/Packages/User (Cmd + Shift + G in Finder). Copy the *.py package into that directory and Sublime will automatically detect it and compile. In the case of Glue Views, the developer included sample key bindings within the comments of the Python code. His didn’t work for me so I created my own:
[
{ "keys": ["alt+equals"], "command": "glue_views_add"},
{ "keys": ["alt+minus"], "command": "glue_views_remove"},
{ "keys": ["ctrl+alt+0"], "command": "glue_views_clear"}
]
Paste those into the Default (OSX).sublime-keymap file. If you want a separate menu for the plugin or all your plugins, create a file (in the same directory listed above) named Main.sublime-menu and put something similar to the following in it:
[
{
"caption": "Plugins",
"mnemonic": "l",
"id": "plugins",
"children":
[
{
"caption": "Glue",
"mnemonic": "G",
"id": "glue",
"children":
[
{ "command": "glue_views_add", "caption": "Add View", "mnemonic": "A" },
{ "command": "glue_views_remove", "caption": "Remove View", "mnemonic": "R" },
{ "command": "glue_views_clear", "caption": "Clear Views", "mnemonic": "C" }
]
}
]
}
]
That gives you a permanent Plugins menu to which you can add menus and commands for other plugins.
Apple has done a tremendous job marketing the new iMac on its website. If you didn’t know any better, you’d think the iMac was only 5mm thick and flat on the front and back.
I found only two images on the site that model a profile view of the new iMac: on the design page and in the Apple store under the gallery tab. The first shows the progression of the iMac over the last 14 years.
The second image is much more detailed and much larger.
Other than these two images, I doubt you’ll find another image on the site that shows the the back of the iMac peaking out from behind the screen. All the images displaying the iMac are captured so it looks like a flat monitor. That’s exceptional marketing. Granted, the back isn’t any deeper than it was before (at least I don’t think it is), it’s pretty obvious they purposefully don’t allow it to show. Furthermore, I couldn’t find a specification anywhere that said how “deep” the iMac is from the front of the screen to the apex of the dome-back (not including the stand). Maybe it’s actually deeper than the previous model and that’s why they won’t tell us. Hmmm…
As I was toying around with pricing on the 27″, I was frustrated because you can’t customize the iMac with anything less than 768GB of flash storage. While I’d love a solid state drive that big, I can’t fork out $1,300. I’d prefer an internal 256GB SSD and then just add a 1TB external drive connected via USB3 or Thunderbolt. But I guess they want to discourage that, thus the 768GB SSD or a fusion drive alternative, which isn’t a terrible idea for an extra $250.
Now the question is, do I buy a new iMac when I graduate or more lenses for my DSLR? :)