In Xerox’s demo, the scroll bar of one particular application has multiple scrolling operations depending on which mouse button is pressed that only get invoked when that same button is released. Even today’s users with decades old scroll bar experience would struggle to understand this implementation. I can’t imagine it being intuitive in 1982 when most computer users had no concept of a mouse driven user interface, let alone scrolls bars.
Stack Overflow still uses Microsoft products. Microsoft infrastructure works and is cheap enough, so there’s no compelling reason to change. Yet SO is pragmatic. They use Linux where it makes sense. There’s no purity push to make everything Linux or keep everything Microsoft. That wouldn’t be efficient.
Stack Overflow still uses a scale-up strategy. No clouds in site. With their SQL Servers loaded with 384 GB of RAM and 2TB of SSD, AWS would cost a fortune. The cloud would also slow them down, making it harder to optimize and troubleshoot system issues. Plus, SO doesn’t need a horizontal scaling strategy. Large peak loads, where scaling out makes sense, hasn’t been a problem because they’ve been quite successful at sizing their system correctly.
[…]
Is 20 Gb massive overkill? You bet your ass it is, the active SQL servers average around 100-200 Mb out of that 20 Gb pipe. However, things like backups, rebuilds, etc. can completely saturate it due to how much memory and SSD storage is present, so it does serve a purpose.
[…]
Go into the IL (assembly language of .Net). Some coding is in IL, not C#. Look at SQL query plans. Take memory dumps of the web servers to see what is actually going on. Discovered, for example, a split call generated 2GB of garbage.
[…]
SO goes to great lengths to reduce garbage collection costs, skipping practices like TDD, avoiding layers of abstraction, and using static methods. While extreme, the result is highly performing code.
There are also some comments on Hacker News.
With Xcode 6, we’ve finally arrived: the built-in testing tools are now good enough to use on their own. That is to say, there are no particularly compelling reasons to use any additional abstractions in order to provide acceptable test coverage for the vast majority apps and libraries. Except in extreme cases that require extensive stubbing, mocking, or other exotic test constructs, XCTest assertions, expectations, and performance measurements should be sufficient.
I do find it helpful to use additional macros to make the assertions more concise. For example, I use EQ() instead of XCTAssertEqualObjects(). This was also nice because I didn’t have to change all my code when Apple renamed its macros. I also have macros like EQARRAY() that make it easier to see how the failing object differs from the expected one. And I have ones for structs like NSPoint because Apple removed support for those with XCTAssertEqual() and never added it back.
Tower 2 is now available. I like some of the new features, such as support for multiple windows, the new Open Quickly feature, changing the tabs to a sidebar, sending folder diffs to BBEdit or Kaleidoscope, and the removal of the popovers.
Previous versions would hang forever when there were a large number of changes in the working copy. I think this is fixed—at least I never saw that happen during beta testing.
There are some problems, though:
As smartphones become our primary devices, doing the jobs once held by computers and even televisions, we need a product that can change, like a chameleon, to serve all of these functions.
Before 2010, the extra real estate was unnecessary. After all, we were using phones mostly for making calls, listening to music, or doing a bit of light web-browsing on bad mobile interfaces, making mental notes to do our real work when we got back to our computers.
Today, the web—from site interfaces to television to native apps—is often designed primarily for the mobile format. The smartphone is no longer just a phone, but a hybrid of devices—and increasingly, the most common way to interact with the world. A bigger screen allows a mobile device to play all of these roles at once.
I’m still annoyed at having to hand-shimmy, but it seems hard to imagine going back to a 3.5-inch screen after using a 4-inch iPhone 5s. I’m not sure yet whether a phone that’s between the size of a 5s and an iPad mini would be perfect or too large for my pockets and hands.
Other than access control, no big changes to the language with Beta 4, unlike with Beta 3. But still plenty of changes to the standard library.
RIP CString. It’s now all ConstUnSafePointer<Int8> all the time. I still can’t get most of my straight C stuff ported but it looks like things are getting closer.
So if internal access is the default, and I don’t want to use it (or want to use it exceedingly sparingly), what do I do?
Update (2014-07-24): Apple:
In Xcode 6 beta 4, Swift adds support for access control. This gives you complete control over what part of the code is accessible within a single file, available across your project, or made public as API for anyone that imports your framework.
James Somers (via Gabe Weatherhead):
I could go on forever listing examples. I could say, “Look up example, magic, sport. Look up arduous, huge, chauvinistic, venal, pell-mell, raiment, sue, smarting, stereotype. Look up the word word, and look, and up. Look up every word you used today.” Indeed that’s what motivated this post: I’d been using Webster’s dictionary for about a year; I kept looking words up, first there, then in whatever modern dictionary was closest to hand, and seeing this awful difference, evidence of a crime that kept piling up in my mind, the guilt building: so many people were getting this wrong impression about words, every day, so many times a day.
There’s an amazing thing that happens when you start using the right dictionary. Knowing that it’s there for you, you start looking up more words, including words you already know. And you develop an affection for even those, the plainest most everyday words, because you see them treated with the same respect awarded to the rare ones, the high-sounding ones.
[…]
Note that the modern Merriam-Webster, even though it does derive directly from Webster’s original, has been revised so much that it’s actually less similar, content-wise, than some of the impostors. It, too, is one of the “wrong” dictionaries.
He has a tip for how to get the Mac OS X dictionary app to use Webster’s 1913 dictionary instead of Oxford.
Update (2014-07-23): Brent Simmons:
(Byron. Wow. I like a metaphor like that because you learn something about both sides, about the Almighty and tempests both.)
This is after two minutes of clicking around. There’s an entire language of rewards in there.
The New Yorker (via Jason Kottke):
Beginning this week, absolutely everything new that we publish—the work in the print magazine and the work published online only—will be unlocked. All of it, for everyone. Call it a summer-long free-for-all. Non-subscribers will get a chance to explore The New Yorker fully and freely, just as subscribers always have. Then, in the fall, we move to a second phase, implementing an easier-to-use, logical, metered paywall. Subscribers will continue to have access to everything; non-subscribers will be able to read a limited number of pieces—and then it’s up to them to subscribe. You’ve likely seen this system elsewhere—at the Times, for instance—and we will do all we can to make it work seamlessly.
[…]
Beginning this week, every story we’ve published since 2007 will be available on newyorker.com, in the same easy-to-read format as the new work we’re publishing.
It’s not entirely clear, but it sounds like the articles will all be available in a Web-friendly format. Previously, I had no interest in paying for the digital edition because the only fully accessible articles were the free ones; the ones with the blue padlocks were only readable via a different Web site that essentially looked like giant screenshots of the printed pages.
But even the Cocoa version of InDesign is not a great platform citizen. OS X reports that it always uses significant energy, even when idle. Its dialog boxes are just an NSWindow with an NSView. Adobe draws text and buttons in the NSView, and tracks mouse clicks in the view manually. Since there are no NSTextFields or NSButtons, these dialogs are completely invisible to screen readers.
This is in stark contrast to Lightroom, which was written with Cocoa in mind from the beginning. It's still a cross-platform app, but all of its UI elements are subclasses of Cocoa classes. The app is accessible, and it doesn't use significant energy while idle. More importantly, it can quickly adopt new features of the OS.
[…]
There are many features of Swift that make it a great language for Apple to write its future frameworks in. It probably won't be long until some of these frameworks start to use Swift-only features like generics. Taking full advantage of platform improvements requires adopting new frameworks, and any Objective-C programs that wants to use these frameworks will need to write adapter code in Swift.
But Swift and Objective-C have different design philosophies. As time goes on, it will be harder to reconcile Objective-C's design philosophy with native Swift frameworks. In order to simply get their apps to work, developers will spend a lot of time figuring out how to refactor their existing Objective-C codebases to fit within the constraints imposed by Swift, leaving them with less time for other improvements.
Update (2014-07-23): Chris Lattner:
Swift is a new option for developing on the platform. We have no plans to drop C, C++ or Objective-C. If you’re happy with them, please feel free to keep using them.
Of course, that’s what Apple said about Carbon as well.
Though the app stores continue to fill up with ever more mobile applications, the reality is that most of these are not sustainable businesses. According to a new report out this morning, half (50%) of iOS developers and even more (64%) Android developers are operating below the “app poverty line” of $500 per app per month.
[…]
The report’s authors detail the specifics around the trend where a tiny fraction of developers – actually, it’s 1.6% to be exact – generate most of the app store revenue.
[…]
Accounting for 47% of app developers, the “have nothings” include the 24% of app developers – who are interested in making money, it should be noted - who make nothing at all.
Meanwhile, 23% make something, but it’s under $100 per month. These developers are sometimes unable to cover the basic costs of development PCs, test devices, and an account to publish apps, the report states. However, in case you’re wondering why so many developers still go iOS first, it’s because those who prioritize iOS app development are less likely to find themselves in this group, with 35% earning $0-$100 per month, versus the 49% of Android developers.
