– John Gruber’s overriding guideline for iPhone UI design
The styleguide is a resource for designers, product managers, and developers, providing a common language around Yelp’s UI patterns. We use it to maintain modular front-end code and visual consistency across the web app.
I like this snippet of accidentally-captured conversation between Barack Obama and British MP, David Cameron. Cameron asks Obama if he will be taking any time off for a vacation this summer:
Mr. Cameron: Do you have a break at all? Mr. Obama: I have not. I am going to take a week in August. But I agree with you that somebody, somebody who had worked in the White House who — not Clinton himself, but somebody who had been close to the process — said that should we be successful, that actually the most important thing you need to do is to have big chunks of time during the day when all you’re doing is thinking. And the biggest mistake that a lot of these folks make is just feeling as if you have to be … Mr. Cameron: These guys just chalk your diary up. Mr. Obama: Right. … In 15 minute increments and … Mr. Cameron: We call it the dentist waiting room. You have to scrap that because you’ve got to have time.
This encourages and inspires me. If people as busy as these two guys (or Bill Gates, for that matter) can make time to rise above the noise, it’s hard to imagine why each of us wouldn’t want to occasionally unchalk our diary enough to try something similar.
A curated list of amazingly awesome PHP libraries, resources and shiny things.
Libraries for package and dependency management.
Libraries related to package management.
Web development frameworks.
Web development frameworks’ standalone components.
Micro frameworks and routers.
Modern content management systems.
Libraries and tools for templating and lexing.
Libraries for working with HTTP and scraping websites.
Libraries for parsing URLs.
Libraries for sending and parsing email.
Libraries for file manipulation and MIME type detection.
Libraries for working with streams.
Libraries that implement the dependency injection design pattern.
Libraries for manipulating images.
Libraries for testing codebases and generating test data.
Libraries for generating project documentation.
Libraries for generating secure random numbers, encrypting data and scanning for vulnerabilities.
Libraries and tools for analysing, parsing and manipulation codebases.
Project build and automation tools.
Tools for managing, compressing and minifying website assets.
Libraries for geocoding addresses and working with latitudes and longitudes.
Libraries for working with dates and times.
Libraries that are event-driven or implement non-blocking event loops.
Libraries for generating and working with log files.
Libraries and applications for taking payments and building online e-commerce stores.
Libraries and software for working with PDF files.
Libraries that implement object-relational mapping or datamapping techniques.
Libraries for working with “NoSQL” backends.
Libraries for working with event and task queues.
Libraries and software for indexing and performing search queries on data.
Libraries for building command line utilities.
Libraries for implementing authentications schemes.
Libraries for working with markup.
Libraries for parsing and manipulating text and numbers.
Libraries for filtering and validating data.
Libraries and web tools for developing REST-ful APIs.
Libraries for caching data.
Libraries that implement data structure or storage techniques.
Libraries for working with notification software.
Libraries for accessing third party APIs.
Useful libraries or tools that don’t fit in the categories above.
Software for creating a development environment.
Various resources, such as books, websites and articles, for improving your PHP development skills and knowledge.
Useful web and PHP-related websites and newsletters.
Fantastic books and e-books.
General web-development-related reading materials.
PHP-releated reading materials.
Reading materials related to the PHP internals or performance.
"Today’s NY Times delivers a great story of the development of the iPhone by Apple. It focuses on the events during the leadup to Steve Jobs taking the stage with shockingly buggy prototypes and pulling off the show that is now history. ‘Only about a hundred iPhones even existed, all of them of varying quality. Some had noticeable gaps between the screen and the plastic edge; others had scuff marks on the screen. And the software that ran the phone was full of bugs. The iPhone could play a section of a song or a video, but it couldn’t play an entire clip reliably without crashing. It worked fine if you sent an e-mail and then surfed the Web. If you did those things in reverse, however, it might not. Hours of trial and error had helped the iPhone team develop what engineers called “the golden path,” a specific set of tasks, performed in a specific way and order, that made the phone look as if it worked.’ One of the big problems was the phone’s connectivity. The man in charge of the iPhone’s radios, Andy Grignon, had to deal with Jobs’s anger when rehearsals didn’t go well. Grignon said, ‘Very rarely did I see him become completely unglued — it happened, but mostly he just looked at you and very directly said in a very loud and stern voice, “You are [expletive] up my company,” or, “If we fail, it will be because of you.” He was just very intense. And you would always feel an inch tall.’”
The whole story is a great testament to engineers, in that (a) it’s incredible they could have made the demo work that well, and (b) Apple actually shipped the thing described in that story just six months later - and it was basically pretty functional and solid.
Even for you Apple Haters out there that have zero interest in reading something like this - well anyone who is an engineer should read it, and if you can’t bring yourself to do that at least read the very last paragraph which is fun for everyone.
- via /..
Why do we pirate music, software and television and movies? It’s not all about the money, mostly. There is/was a french project Pourquoi je pirate where random strangers were asked why do they pirate, I present you few of my fav responses. Please see that these responses are a direct translation from french.
By selling the tickets exclusively on my site, I’ve cut the ticket charges way down and absorbed them into the ticket price. To buy a ticket, you join NOTHING. Just use your credit card and buy the damn thing. opt in to the email list if you want, and you’ll only get emails from me.Also, you’ll see that if you try to sell the ticket anywhere for anything above the original price, we have the right to cancel your ticket (and refund your money) this is something I intend to enforce. There are some other rules you may find annoying but they are meant to prevent someone who has no intention of seeing the show from buying the ticket and just flipping it for twice the price from a thousand miles away.The consumer wants control. They want freedom. Give people what they want, when they want it, in the form they want it in, at a reasonable price, and they’ll more likely pay for it rather than steal it.
Post-it notes are more powerful tool than most people realize because they:
The entire application’s code is stored in a single revision control repository. If you have multiple repositories for different parts of the software, you should consider them to be separate applications that treat each other as services. If you have multiple applications in a single repository, you should factor out whatever they both use as a library they both depend on and then split them into two codebases.
For your revision control system, you will probably want to use git, because it’s the most featureful and most popular.
All your dependencies should be explicitly declared. In Ruby you can do this with a
Gemfile, in Python with
requirements.txt, etc. Locally, you should use a tool like
virtualenv to isolate your environment to make sure you aren’t using any undeclared dependencies.
All configuration values should be stored as environment variables. This includes anything you’d be afraid of making public, like passwords or secret keys, as well as anything that might be different from deploy to deploy, including the locations of databases or the administrator email address.
All backing services (like databases or in-memory caches) are treated as services. No distinction is made between local and third-party services; they’re all accessed over the network.
Code is deployed in three separate stages: build (in which the software is compiled and built), release (in which it’s combined with the configuration environment and put onto the appropriate servers), and run (in which it’s executed). These stages should be completely isolated – the server can’t change its configuration at runtime, since the release stage has already been passed. And the release process can’t edit the software, since the build stage has already passed.
The application should execute as a series of stateless processes that share nothing – any process should be able to be killed at any time. This means any state needs to be stored in one of the backing services.
The application should be completely self-contained and contact the outside world through an IP port (designated by the
$PORT environment variable). It shouldn’t be expecting to live inside some sort of larger process.
The application should be made up of various process types and be able to scale by starting more instances of these process types. For example, if there’s a lot of web traffic, you should be able to handle it by starting more instances of the
web process type.
Processes should be disposable – you should be able to start them and stop them at a moment’s notice, without any harm.
The gap between development and production should be kept small – the same backing services, dependencies, and team should be used in both places. Development is just another deploy of the application with a slightly different config.
Logs are just a stream of events written unbuffered to
stdout. It’s not the application’s job to make sure they get to the right place; that’s the job of the infrastructure.
Administration tasks should be run as one-off processes.