Clojure keeps growning up, and my 2.5-years old guide for setting up Clojure environment on Mac OS X had been out-of-date for quite a while. The toolchains based on Leiningen 2 and nREPL rise from underground, become really powerful and easy (even joyful for most of us) to use, and de facto standard. Nearly all main stream developing environments provide solutions for serious Clojure developers: Eclipse + Counter Clockwise, IntelliJ IDEA + La Clojure, Sublime Text 2 + SublimeREPL, Vim with fireplace.vim, etc., and the favorite I finally found several months ago, Emacs Live.
In my opinion, the major tasks for Apple in this year are all about software, especially in the iOS eco-system.
iOS has very solid Unix foundation and decent application framework. For a long time iOS had incontrovertible advantages over its rivals: performance, security, smooth user interaction, etc., most of which are still advantages today. But we all know that some incapabilities in iOS, especially compared to Android, are becoming more and more important aspects that Apple cannot ignore. Consider the following facts: Android may not be rendering the UI animation as smoothly as iOS always does, but it’s been getting better and better since Android 4.0, while iOS still doesn’t allow third-party apps customize the lock screen or put widgets on any part of the main UI. See the difference? Android’s problems are ‘not as good as iOS’ and iOS has some incapabilities. If Apple want more people to choose iOS it should persuade the swing people (not the fans) that iOS is better in all aspects. It’s a prerequisite to eliminate those incapabilities ASAP.
Ars Technica posted their staff wish list for iOS 7 last week. Most features in their list are good ones but not the critical ones. Base on the above eliminating incapabilities theory I’ll list mine below, divided to developer and user categories.
In the first part of this series we have discussed the core concepts of RESTful architectural style and gives some guideline in how to define the system and prepare for defining the APIs specs, which will be covered in this part.
Level III: Define and Tune the API
Defining API specs is the most important part of all and it’s a continuous progress in the whole lifecycle, mostly documentation oriented. A simple and neat document collaboration platform is very useful. I suggest facilitating tools such as MediaWiki or Markdown + GitHub etc. Then you can follow these sections below.
I spent my summer vacation with my family in Germany, Austria and Switzerland. It’s the first time I visit Europe. Had bunch of photos, most of which are taken by my Fujifilm Finepix X100 with its wide conversion lens WCL-X100. After one and half months I finally picked up ~150 photos and uploaded them to 500px.
X100 is a really amazing camera. Its top-of-the-line APS-C sized CMOS sensor provides great resolution and SNR. Its prime lens (with field of view equivalent to 35mm and 28mm lens on full frame) are especially suitable for landscape and cultural photography. iPhone 4S is a great backup, provide fairly good photos even in some typically difficult scenarios for compact DCs. Remember all these are very lightweight. Farewell my big DSLRs. The best cameras are the ones you always take with you.
As for the digital darkroom, Aperture is a perfect tool both on organising and editing. And the 500px Uploader developed by iKenndac significantly simplifies the process of uploading photos to 500px. But I have some serious suggestions for 500px. Yep, this is the real reason I wrote this blog.
Per my 13-years old daughter’s request I’m searching for some tools to build her own image website, so she can publish and manage all her drawings and photos. To my surprise after all these years there are still very few such tools that not sucks.
Gallery, Piwigo, Zenphoto, E2 Photo Gallery, etc. They are old, powerful and actively developed. But all of them are so last-century. They are ancient content manage systems and just not work for modern creative artists, like my daughter of cause. Here is my requirements:
- Free and open source (optional)
- Easy to deploy to shared hosting service and/or VPS
- Easy-to-use uploading tool which supports single and multiple files
- Support imagesets (“albums”)
- Support tags
- Manageable commenting and rating system (built-in or integration with Disqus)
- Support direct hyperlinks to the images (can be toggled on/off per album based)
- Sharing button for Twitter and other social networks
- Automatically EXIF/IPTC handling
- Thumbnail view with AJAX based in-place zooming and editing (for meta info)
- Cool built-in themes (at lease 2 for dark and light backgrounds), simple but working customizing system
- Support iPhone and iPad-size mobile devices
- Support i18n
- Easy to backup/restore or export/import
- Acceptable performance for hundreds of images
Many say that
WS-\* suck and SOA is over or becoming profit tool for big consultant companies. But I would say: SOA is not evil, IBM is. Look at these principles of SOA:
- reuse, granularity, modularity, composability, componentization and interoperability.
- standards-compliance (both common and industry-specific).
- services identification and categorization, provisioning and delivery, and monitoring and tracking.
All these are perfect software architectural styles(well, except those words your spell checker complains), our best dream. These can’t be wrong. The problem is in the implementations. Fortunately the rises of RESTful services on the open web prove that the spirit of SOA can really matters. Maybe one day similar architecture and implementation will eventually change enterprise computing in return.
I always believe the service-oriented architecture will be the future of massive distributed software system. And RESTful services will replace web sites and eventually become the main body of the Internet. So I often think about how to help approaching it. I know that lots of people want to implement RESTful style services in their system (though they may not know what for). What they need is a brief and clean(maybe not extremely accurate and complete) guideline when practicing RESTful services. It can help to make things right and avoid traps such as using HTTP request as RPC protocol – it can be used as RPC protocol but it’s not RESTful and cannot provide key benefits which REST want to apply.
I tried Paper for several hours. It offers no unique features. It’s much less powerful than AutoDesk’s SketchBook Pro, a full-featured paint tool especially designed for the new iPad’s Retina Display which was showed off on Apple’s event. But I can predict that Paper will be much more popular. So why is it so special?
Watch their official trailer and you can get some clues. The trailer spreads several important ideas: 1. Paper can be used anytime anywhere whenever people want to use pen and paper. 2. The User, the iPad, Paper and the stylus work together as a whole. 3. All these are all about the user’s lifestyle, becoming part to it.
So what do you think while watching the video? Desire to light up your iPad at once and sketch something? Think about buying one Wacom Stylus for your iPad? Or those amazing ads for the original iPad? My answer is: all of them. And one more
thing person, Don Draper.
Go is the language from Google and Android is the mobile OS from Google. The bond between them are just born with. So there should be no surprise that we can use Go to write Android programs, though some important restricts for now:
RestKit is an amazing Objective-C framework for iOS that aims to make interacting with RESTful web services simple, fast and fun. As said on its homepage:
It combines a clean, simple HTTP request/response API with a powerful object mapping system that reduces the amount of code you need to write to get stuff done.