Who doesn't want their apps to integrate with Facebook? the second most popular site worldwide, and most popular, bar none, in eight countries (according to Alexa)? Well, Facebook loves PHP, and even offers a PHP SDK for the Facebook API. The API is available on Github, with examples -- so browse the SDK directly, if you like. Or try this new tutorial from phpmaster.com. The author, Hari KT, introduces the guide: Integrating with Facebook from PHP is easy with the help of Facebook’s PHP SDK and some HTTP libraries like Zend_Http_Client or PEAR HTTP_Request2. In this article I’ll show you how to get started using the Facebook PHP SDK. You’ll learn about the Facebook Graph API and create a Facebook application capable of updating your status message and uploading photos. Hari runs through initial setup, explains, the Graph API, and provides a sample ('Hello Facebook') application. It looks pretty easy, and could lead to something supremely cool. Check out the SDK here, and the tutorial here.
Suffering a little whiplash after the rapid-fire removal and return of HTML5's element, I became curious about how the working groups at W3C actually, well, work. In particular, I noticed something about the wording of Steve Faulkner's original revert request: the editor of the HTML5 specification has made a change to the specification that is not supported for good reasons (see below, source: http://willyou.typewith.me/p/9Zl7I2dOKs) I therefore request a revert of this change http://html5.org/r/6783, so that it can be further discussed and decided within the consensus based HTML WG process. Emphasis (er, offset) added. The editor-vs.consensus theme chimed with an early, rather severe response to the original decision, calling Hickson's move 'self-contained'. Okay, everybody likes consensus, especially about standards. But the once-upon-a-time student of decision theory and commitment devices in me perks up skeptically at (even implicit) accusations of unilateralism. Lucky for me, an Invited Expert from the CSS Working Group at W3C has already posted a thorough treatment of how the CSS group works. The inside-view really gives a better feel for how people really act in the CSS group -- more than, for example, the official charter and process document of the HTML Working Group (which are very top-down, as presumably documents of this sort must be). CSS isn't HTML, of course. But CSS is now being developed in modules, rather than tangled, monolithic versions; and one of the differences between W3C and WHATWG (the 'other' HTML5 standards group) is that W3C is maintaining the kinda-versioned 'HTML5' designation, while WHATWG now treats HTML as a 'living standard' (complete with an exacting list of differences between the W3C and WHATWG specs). So versioning is a bit of a thorny point in both HTML(5) and CSS, and the issue of versioning must deeply affect any standards-regarding decision-making process. Indeed, the 'Inside View' grants modularization a whole page to itself. The full site goes into a lot of gritty details -- interesting for anyone interested in decision-making at this level, but especially for anyone involved in defining new web standards. But most of us aren't defining new web standards. So, for the rest of us, here's an outline of how the CSS Working Group does its thing, in tl;dr form: People and Roles: module editors (in charge of each module) CSS WG members (inner group of discussants) www-style contributors (all other discussants) Communication: mailing lists (technical discussions; high volume; members follow closely) telecons (1hr, once/wk; chair presides, scribe takes minutes) face-to-face meetings (3 full workdays, 3-4 times a year; half in USA, half split between Europe and Asia; one meeting takes place along with other W3C groups; addresses deepest/hardest/complexest issues) IRC (side-discussions during official telecons; unofficial chats) internal mailing list (mostly just planning meetings and other administrative tasks; any technical discussion is immediately moved to the public www-style list) www.w3.org (homepage with specs and blog) dev.w3.org (editor's draft specs, with revision history) wiki.csswg.org (lots of stuff, technical and administrative; general-purpose, like any good wiki) test.csswg.org (subdomain=giveaway) Making Decisions (usually somewhat informal; for this one read the full treatment) Modularization (first formulated during 2007 CSS-WG meeting in Beijing; page includes history and rationale) Spec Process: working draft (with numbered iterations, until Last Call Working Draft) candidate recommendation (calls for implementations; this usually means lots of implementations already exist) recommendation (=finished; arrived at only after two correct independent implementations exist) Sources of Innovation (full post discusses three different sources for CSS3 Backgrounds and Borders) Makes sense to me. The site is much more discursive than this outline summary -- and the discursiveness gives a better feel for what it's like to participate in the WG, so the read is pretty fascinating.
In this article, we will review various options to store long text in the PostgreSQL database: @Lob attributes, TEXT, and long VARCHAR table columns. Also, we'll have a look at the difference between Hibernate 5 and 6 in storing long text data.
ScaleGrid’s MySQL on AWS High-Performance deployment can provide 2x-3x the throughput at half the latency of Amazon RDS for MySQL with their added advantage of having two read replicas as compared to one in RDS.