“We are happy to confirm that Android Studio, the new IDE for Android development that Google is developing in cooperation with JetBrains, is based on the IntelliJ Platform and the existing functionality of IntelliJ IDEA Community Edition.” —
JetBrains is one of the best developer tools companies out there IMO. I have happily paid for PHPStorm and RubyMine out of my own pocket as the apps are just worth it.
Congrats to the JetBrains team and Android developers everywhere. You no longer have to use Eclipse!
“The problem comes from the fact that the new Ruby 1.9 installation doesn’t find the certification authority certificates (CA Certs) used to verify the authenticity of secured web servers.” —
Ruby 1.9 and the SSL error « Martin Ottenwaelter
If using Homebrew instead of port:
brew install curl-ca-bundle
TL;DR: PHP is still a poor choice for continually-running processes. See this post for context. Read on for more proof.
There’s been some reaction to the previous entry. Some people agreed, mostly seasoned PHP folks, some others just didn’t. Yeah, apparently it pleased or infuriated more than two folks in the entire Internet.
First and foremost, a correction to previous statements: PHP’s 5.3+ enables garbage collection by default, it’s an opt-out feature, not opt-in. So it’s probably enabled in all your scripts, even the fast-dying ones, if your PHP version is recent enough and you didn’t do anything funny to your php.ini file.
Yes, I already acknowledged that PHP has a garbage collection implementation starting 5.3.0 and up (opt-in or opt-out, that’s not the problem). I also acknowledge that garbage collection works, and is able to take care of most circular references just fine. However, if you’re one of the many that think “hey, no one should be using anything below PHP 5.4 nowadays”, you’re clearly too young to remember how much blood, sweat and years it took to get rid of PHP 4, even when PHP 5.0 was reaching end-of-life, 5.1 was healthy, and 5.2 was already in the works.
Anyway, as previously stated too, garbage collection is a great thing, but not enough for PHP. It’s a borrowed feature that does not play well with old fundamental decisions inherited from the original design. Garbage collection is not a magical solution for every problem, like many tried to argue about. Let’s illustrate with another example.
Very interesting read. PHP dying at the end of every request is a feature of the language, but can lead to some problems if you want to use it for long-running processes.
Created a new server today. Continuing my Doctor Who theme, this time I have a Dalek. EXTERRRRRMINAAAATE.
Recently, I’ve been looking at various deployment strategies. I’ve spent a lot of my career doing some configuration management, mostly out of necessity where I’ve been the lead developer on a small team. Over the years, I’ve written several deployment scripts. For employers, they’ve always been built on top of SVN and Fabric. Since I didn’t want to use SVN for my personal projects but was familiar with Fabric, this morphed into a project called Fabox, which used Dropbox as a VCS, and Fabric as the CLI to deploy the code. I’ve talked about Fabox before. I used it for awhile but it was too involved for my simple personal projects (Fabric was overkill for my single-server environment). I’ve also soured a bit on Dropbox lately, since their customer support has been completely non-existent.
After Fabox, I wrote a PHP-based deployment server called Giply. It is built on top of Git, and utilizes a common feature with popular Git hosting services Github and Bitbucket where you can POST a payload to a URL. As a web service, Giply consumes these payloads and updates the Git repo automatically.
I took the concepts I learned while writing Giply and vastly improved it with Ripple. Ripple is built in Ruby and includes basic authentication support, easy restoration to previous deployments, and a full featured CLI. It includes a web service like Giply, but it can also be completely managed through the console script.
Since I’ve begun using Ruby for all of my personal projects, I find it really great. Obviously if you don’t have your server environment set up for hosting Ruby (specifically Sinatra), it would probably be a more complicated setup than you’d want. This is the only area where Giply excels. Giply is dead simple to use in a server environment if you have a LAMP stack already created.
There are obviously many other ways to deploy code. Ripple has worked for me in my single-server, no fuss environment. When I want to update the server code, I just push to my Bitbucket repo which POSTs to the Ripple URL I set up in Bitbucket and the rest is handled automatically. It will update projects written in any language, but I’ve added hooks for Bundler in Ruby and Composer in PHP since I use both in my side projects.
For multiple-server environments, there are many options. If you want your scripts written in a particular language, you have several popular options: Fabric (Python), Capistrano (Ruby), and Phing (PHP). These projects all work using SSH to connect to the servers they manage. I’ve personally used Fabric the most, and wouldn’t touch Phing unless I was paid to. Since I love Ruby, I want to try Capistrano but haven’t had the need.
If you’re interested in any of these deployment projects, they’re in my Github. Feel free to use them in your own projects.