PHP-GTK Community : a community site for PHP-GTK

Bienvenue dans ce flux Google Alertes. Il vous permettra de recevoir de nouvelles alertes concernant votre requête Tout sur "php gtk". En fonction de votre requête, le délai d'affichage du premier élément peut être assez long. Accédez à la console de gestion des alertes pour modifier ou supprimer la demande d'alerte. Merci de votre confiance.

When I was in school, passing notes took some effort. First, you needed to find a piece of paper that was large enough for your message, but small enough that it could be folded into the requisite football shape. Next, you had to write something. Anything smaller than several sentences just wasn’t worth the overhead, so you had to write about half a page’s worth of stuff, or draw a picture large and detailed enough to make it worth it. After that, you set about the process of folding your note into the aforementioned form. Finally, you had to negotiate with your neighbor to get the note from your desk to its final destination. All that was just to send the message. On the receiving side, the note was unfolded and read. Then your counterpart would go about constructing a response, refolding the note, and negotiating the return trip.

http://www.flickr.com/photos/kmorely

Passing notes in class was a task that required effort, skill and time. You sent a message and you waited for a response. If you thought of something new that you really needed to say, you had to wait until the response came back. At that point, you could alter your original message or add new content. While your note was in transit or being read and replied to on the other end, you had no control. You were at the mercy of the medium over which you were forced to communicate. Note passing simply isn’t designed to allow for short, quick, asynchronous communication.

Nowadays, kids just text each other on their smartphones. They send messages quickly and easily without having to invest in all that overhead. After a bit of upfront work to get someone’s phone number, the back channel classroom chatter flows freely. That is, until someone forgets to silence their phone and the teacher confiscates everything with a battery.

Just as the methods of slacking off in school have evolved, so have methods of communicating over the Web. HTTP is the note passing of the Internet. It works well enough for most communications, and when the message is large enough, the overhead is minimal. However, it is less efficient for smaller messages. The headers included by browsers these days can easily outweigh the message body.

Also, just like note passing, HTTP is synchronous. The client sends a request and waits until the server responds. If there is something new to be said, a new request is initiated. If the server has something to add, it has to wait until it is asked. It can’t simply send a message when it is ready.

WebSockets are the smartphone to HTTP’s notes. They let you send information quickly and easily. Why go through all that folding when you can simply send a text to say “idk, wut do u think we should do?” Why use 1K of headers when all you want to know is, “Did someone else kill my rat?” Better yet, why ask at all? Why not have the server tell you when the rat has been killed by someone else?

WebSockets are made for small messages. They are made for asynchronous communications. They are made for the types of applications users expect these days. That’s why I like WebSockets so much. They let me communicate without overhead or rigorous process. I can write an application that is free from request/response pairs. I can write an application that responds as quickly as my users can act. I can write the applications that I like to write.

Earlier today, David Soria Parra declared a feature freeze on PHP 5.5 and tagged php-5.5.0beta1, but not before merging in pull request #257, which includes my humble addition to the PHP programming language: array_column().

The story of array_column() begins at PHP Tek in 2008. As I recall, it was Spooons who suggested it to me. It is functionality that nearly every developer has to implement in user-land code at some point in their careers, so I felt it only natural that it be built into the language, so I did just that.

My original patch for array_column() was written for PHP 5.2, but it sat around collecting dust for many years, until April of last year, when PHP moved to git and GitHub. That’s when it became easy enough to apply the patch and send a pull request, which I did. It wasn’t quite that simple, though, since I had to follow the official PHP project RFC process, but it wasn’t a pain either.

My goal for array_column() was simplicity. Many implement the functionality in different ways, and many call the function by other names (such as “pluck”), but I wanted to keep it simple and recognizable. It follows this function signature:

1 array array_column(array $input, mixed $columnKey[, mixed $indexKey])

Given a multi-dimensional array of data, array_column() returns the values from a single column of the input array, identified by the $columnKey. Optionally, you may provide an $indexKey to index the values in the returned array by the values from the $indexKey column in the input array.

For example, using the following array of data, we tell array_column() to return an array of just the last names, indexed by their record IDs.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 <?php $records = array( array( 'id' => 2135, 'first_name' => 'John', 'last_name' => 'Doe' ), array( 'id' => 3245, 'first_name' => 'Sally', 'last_name' => 'Smith' ), array( 'id' => 5342, 'first_name' => 'Jane', 'last_name' => 'Jones' ), array( 'id' => 5623, 'first_name' => 'Peter', 'last_name' => 'Doe' ) ); $lastNames = array_column($records, 'last_name', 'id');

If we call print_r() on $lastNames, you’ll see a resulting array that looks a bit like this:

1 2 3 4 5 6 7 Array ( [2135] => Doe [3245] => Smith [5342] => Jones [5623] => Doe )

And that’s all there is to it. I hope you find my little addition to the PHP language helpful. I had a lot of fun writing it, and following the PHP RFC process was a great learning experience.

Twitter pretty much killed blogging for me. When I signed up for the service six years ago, I was blogging quite a bit, but Twitter’s rapid-fire, ultra-short status updates have given me a 140-character attention span. Not only did I stop blogging, but I stopped reading blogs, too. Reading and writing became a chore. While I could fire off a message on Twitter within minutes or seconds of crafting it, blogging was an endeavor that took much longer—hours or even days, at times.

You see, the thing is: I care about the words I write. Probably too much. But with Twitter, I stopped caring. Its ephemeral nature means I don’t have to care. Until recently, even searching for posts on Twitter only went back so far. When I blog, I have to read and re-read the words I have written, over and over. This doesn’t stop after I finally decide to publish a post. Instead, I continue to pore over my post, reading it in its published form and eagerly awaiting potential comments. I’m doing it even as I write this. It can be stressful.

When Google announced this week their decision to shut down Google Reader, it stirred up unresolved emotions in me. I know that sounds silly, but while I haven’t been reading or writing blog posts very much over the last six years, the concept of the blog still holds a dear place in my heart. Blogs are important communication and knowledge-sharing tools. They have revolutionized the way we spread information (or mis-information). I believe they are still important and have a continuing part to play in how we communicate with each other. Without the concept of the blog, it would have been impossible for many of the folks we consider leaders in our various technology communities to have had a platform to share their voices and ideas.

Earlier this year, I made a resolution to myself to begin reading blogs again. I returned to the Google Reader account I had set up long ago and connected it to NetNewsWire on my desktop and phone. I have been pretty good about reading things, and I have tried to treat it a bit like I treat Twitter; if I get behind on reading, I just “mark as read” and continue on, without stressing over it. Some of the things I’m reading have been inspiring me to write again, and I felt it was only a matter of time before this incessant writer’s block was broken and the words began flowing freely again. I believe that time is now.

This isn’t a post to discuss the ramifications of Google’s decision to pull the plug on Google Reader. Nor do I want to consider whether blogs are dying. Those are thoughts better left to other bloggers. What I do want you to think about, however, is how blogging has affected you, whether through your own blog or the blogs of others. Has it helped you be more successful? The answer for me is “yes,” and for this reason, I resolve to read even more, be liberal with my comments on others’ blogs, and write without fear.

Thanks goes to Chris Shiflett for inspiring this post. Be sure to take time and read his original Ideas of March post from 2011, as well as his most recent one.

Code is the way in which humans tell computers what to do. Lots of effort has gone into making code easier for humans to read in the form of high level languages like Java or C++ and scripting languages like PHP, Ruby, and Python. Despite mankind’s best efforts, writing code is still clearly an exercise for talking to computers. It has not evolved to the point where talking to a computer is as easy and natural as talking to other people.

That’s why documentation is so important. Programming languages are just a translation of a developer’s intent into something a computer can execute. The code may show the computer what you intended for it to do, but the context is lost when another developer comes back to it later. Computers don’t know what to do with context. If they did, the days of Skynet would already be upon us. Humans can process context and it makes the process of dissecting and understanding a computer program much easier.

I find it both sad and hilarious when I see a speaker evangelizing code without comments. Invariably, the speaker shows a slide with five lines of code and spends ten minutes explaining its form and function. Even the simplest and most contrived examples from some of the foremost experts in the field require context and explanation.

When a bug decides to show itself at three in the morning, in code that someone else wrote, context and intent are two very powerful tools. When bugs are found the question, “What was this supposed to do?” is more common than “What is this thing doing?” Figuring out what it is doing is easier when you have good log data to go on. Knowing what it was supposed to do is something only the original developer can tell you.

If you aren’t aware of the concept of Test Driven Development, I strongly recommend you dig into it. In summary, tests are written before the code to ensure that they code matches the business requirements. I would like to propose a complimentary development driver: Documentation Driven Development. By writing out the code as comments first, you can ensure that the context of the development process will be captured. For example, I start writing code with a docblock like this:

/** * Returns the array of AMQP arguments for the given queue. * * Depending on the configuration available, we may have one or more arguments which * need to be sent to RabbitMQ when the queue is declared. These arguments could be * things like high availability configurations. * * If something in getInstance() is failing, check here first. Trying to declare a * queue with a set of arguments that does not match the arguments which were used * the first time the queue was declared most likely will not work. Check the config * for AMQP and make sure that the arguments have not been changed since the queue * was originally created. The easiest way to reset them is to kill off the queue * and try to recreate it based on the new config. * * @param string $name The name of the queue which will be used as a key in configs. * * @return array The array of arguments from the config. */

Next I dive into the method body itself:

private static function _getQueueArgs($name) { // Start with nothing. // We may need to set some configuration arguments. // Check for queue specific args first and then try defaults. We will log where we // found the data. // Return the args we found. }

After that, I layer in the actual code:

/** * Returns the array of AMQP arguments for the given queue. * * Depending on the configuration available, we may have one or more arguments which * need to be sent to RabbitMQ when the queue is declared. These arguments could be * things like high availability configurations. * * If something in getInstance() is failing, check here first. Trying to declare a * queue with a set of arguments that does not match the arguments which were used * the first time the queue was declared most likely will not work. Check the config * for AMQP and make sure that the arguments have not been changed since the queue * was originally created. The easiest way to reset them is to kill off the queue * and try to recreate it based on the new config. * * @param string $name The name of the queue which will be used as a key in configs. * * @return array The array of arguments from the config. */ private static function _getQueueArgs($name) { static::$logger->trace('Entering ' . __FUNCTION__); // Start with nothing. $args = array(); // We may need to set some configuration arguments. $cfg = Settings\AMQP::getInstance(); // Check for queue specific args first and then try defaults. We will log where we // found the data. if (array_key_exists($name, $cfg['queue_arguments'])) { $args = $cfg['queue_arguments'][$name]; static::$logger->info('Queue specific args found for ' . $name); } elseif (array_key_exists('default', $cfg['queue_arguments'])) { $args = $cfg['queue_arguments']['default']; static:$logger->info('Default args used for ' . $name); } // Return the args we found. static::$logger->trace('Exiting ' . __FUNCTION__ . ' on success.'); return $args; }

The final result is a small method which is well documented and little if any extra time to write.

Armed with data from logs, unit tests which ensure functionality, configurations to control execution, isolation switches to lock down features, and contextual information in the form inline documentation, the process of finding bugs becomes easier. LUCID code communicates as if it were a member of the development team. It does all the things you expect from a coworker. It talks, it makes commitments, it works around problems and keeps a record of both what it is doing and why it is doing it.

Today, we announced the opening of Firebase Beta to the public!

It’s been a few months since I joined the team, and it’s been one hell of a ride. Working at a start-up was everything I imagined it would be, and more. I can easily say that I’ve never been as productive as this before, and that there’s a lot of joy in putting a product that you played a critical role in building, out in the world for every one to see. The best thing about working in a small team who are all in the same room is the speed at which everything moves. It took me an evening to implement Persona support for Firebase, but it took even lesser time to get the feature out to our users. That’s when I learned that the amount of time elapsed between making something and shipping it can play a huge role in motivating me, and I suspect many other developers feel the same way.

Last night the entire team was in the office until midnight, polishing and tweaking everything to make sure we were ready for today’s release. Bugs were found and fixed in minutes. We even managed to implement an entire feature that we decided was important to have. The dedication and caliber of my colleagues continues to amaze me.

The real reward, however, is when I talk about Firebase with other developers. The response has been overwhelmingly positive – from veterans I know at Mozilla to folks who are just learning JavaScript at Meetups. The look on their face when they first understand how Firebase works, that ‘aha!‘ moment, is priceless. A few moments later, you can almost hear their mind sprinting through the possibilities of what they could make.

We have an excellent product, and now is the time to spread the word and help people build amazing things with it. 2013 is going to be a fun and challenging year!

At some point in its life, every team will have a bad egg. If it isn’t a hiring mistake that brings someone in, it can be a business choice or financial change that sours (if even only temporarily) a previously great player. What separates poor and mediocre teams from the great ones is their ability to effectively quarantine the disgruntled teammate until such time as the problem can be corrected. If the group can’t isolate the individual and continue to function at a high level, they run the risk of completely imploding. An ineffective dynamic can spread and negatively impact the entire organization.

The same can be said of an application. Applications are a collection of individual components; they pull together the contributions of individuals to create something which is greater than the sum of its parts. If one piece breaks down, and the system is not prepared to put it in quarantine, the entire application can come crashing down. There are no effective means for isolating the application, if the application is the team member that turns sour. Once this happens, the disease spreads and the entire company is at risk.

The best way to stave off this infection is to prevent it at the source. Keep the application happy by making it more resistant to implosion. Take the team approach down one level, inside your code, and imagine features as team members. If one of piece of the application, such as user authentication, goes a little crazy, will that bring down your entire system? Hopefully, users that are already logged in can still make purchases or update their user information or share links with their friends. Don’t let users that are having trouble logging in ruin the experience for everyone else. That isn’t to say issues with authentication aren’t a major concern, but they should be isolated in such a way that people who are already in can still do what they came to do.

Code jerks (the features, classes and libraries that bring everything else down when they are upset) come in all sorts of shapes and sizes. There are code jerks that hold resources too long. These jerks normally don’t do much on their own, but when you have lots of users executing the same code at the same time, you essentially end up DoS’ing yourself. There are code jerks that assume they know how the rest of the system works. These jerks tend to halt execution and prevent the rest of the application from working around the error. There are code jerks that give up too easily. These jerks try something once and assume things can’t get any better so there is no point in retrying. The worst code jerks are a combination of the three.

Resource hogs are tough to find, because they typically need lots of friends before they are a noticeable problem. For example, setting a connection timeout to five seconds for a third-party service may seem reasonable. However, when the service is slow and it takes three seconds to connect, you could end up keeping your own connections open much longer than expected. Can your server hold each connection open for three seconds and still handle all of the incoming requests? Even if only some of your user requests need this service, you may run out of connections for the rest of your users. Being able to turn this particular feature off without impacting the rest of your site can help keep your application running and making money.

It isn’t always third-parties that cause trouble. Some times it could be your own database that slows down your application. Let’s say you forgot to add an index, or your data suddenly changed dramatically and your old indexes don’t work as well and your database has become unresponsive. Many applications (including most of the ones I have built in the past) assume that not being able to talk to a database is a fatal error. The database wrapper library may halt execution of the app or make it difficult for the application to properly handle the situation. I have since learned that there are lots of things you can do without database access. For instance, depending on your data and your business rules, you may be able to use slightly old cache data in place of fresh database data. If you isolate the your application from certain types of failures, you can let your code decide what is best. Your code should do everything it can to satisfy the user’s request to the best of your ability and be as resilient to failure as your business allows.

Sticking with our database example, let’s look at what you might do when the primary database isn’t available. Assuming you can’t use the cache as a back up database, what can you do? Can you read from a secondary? Can you log data to a temporary location to be written to the database when it comes back up? Is the primary database really 100% critical to satisfying the user’s request? With a bit of creativity you can probably find a solution that allows you to keep the site up while you work to fix the database problem. But even before you get to that point, how do you know you it is really necessary? This may come as a shock to some, but the Internet is unreliable. It tells you something is there one minute, and then that it is gone the next. The inverse is equally true. Just because you tried to connect to the database and couldn’t, doesn’t mean you need to switch to crisis mode. Maybe you were just a victim of the Internet being the Internet. Code that tries multiple (configurable) times to connect to a database isolates the rest of the application from the reliability issues inherent in communicating between systems.

Approaching software as a set of interconnected and unreliable services helps to create applications which stand up better in the face of less than ideal situations. Unfortunately, even when you have an application that communicates well with logs, has tests to verify functionality and uses configurations to help isolate features from one another, there will still be bugs. Armed with your logs and tests, you will still have to dive into code and make changes. The level of documentation in your code can either make this easier, or a nightmare. The next post will look at how documentation contributes to the maintenance of code.

Merge branch 'master' of git.php.net:/php/gtk-src

m tests/GtkCellLayout/get_cells.phpt Added gtk_window_group_list_windows override - thanks to xektrum

m tests/GtkCellLayout/get_cells.phpt Fixed the test expected output

m ext/gtk+/gtk-2.12.overrides + tests/GtkCellLayout/get_cells.phpt Merge branch 'pull-request/1'

m .gitignore Missed yet another gitignore for autotools junk

m ext/gtk+/gtk-2.12.overrides + tests/GtkCellLayout/get_cells.phpt Added brackets around if on gtk_cell_layout_get_cells override in ext/gtk+/gtk-2.12.overrides Added test/GtkCellLayout/get_cells.phpt

m ext/gtk+/gtk-2.12.overrides Added gtk_cell_layout_get_cells override

m demos/examples/signals.php m generator/templates.php m main/phpg_gobject.c Add little hack to make sure user classes get their constructor's run when used with libglade or gtkbuilder and that constructors ar never double constructed Also added signal example for using TYPE_PHP_VALUE

m main/phpg_gvalue.c m win32/config.w32.in m win32/confutils.js Segfault bug on win32 and windows build system issue with the zend destructor using type and getting confused when there was no type - only showed up on release builds on win32 (grrr stupid thing) - also fixed the compiler detection and flags. This probably breaks things for older then 2008 compilers, really don't care

m generator/array_printf.php This officially breaks building with anything less then 5.3 with the generator since it uses closures But I can't get rid the of the /e modifier in the regex without using a closure to wrap up that array information so I'm stuck - either I break the generator for 5.2 or it spews on 5.4 Note this doesn't mean you can't still build against 5.2 you just need php 5.3 cli or higher to do the build

m ext/gtk+/gdk.overrides rest of mac fix with nswindow id or null if another backend is used

m ext/gtk+/gdk.overrides Fix for quartz backend - should return nothing for gdkdrawable xid since the underlying item is an nswindow or nsview but only for gdkwindows

m .gitignore m win32/buildconf.js m win32/confutils.js win32 build fixes buildconf needs to delete the right file, alterations to confutils so the right gtk version is picked up, and fix for regex cause of - in the name plus some missed gitignore entries