In order to take advantage of HTML5’s History API, the application must ignore the URI in the http request and resolve to the root – otherwise you’ll get a 404 error. This can be an issue with a WordPress application because WordPress uses a similar technique by using either Apache or NGINX to resolve all requests to index.php, which then parses the URI and renders the corresponding page/post/archive/ect.
Instead of sending giant payloads or screenshots, send a cURL. From Chrome’s Networking console, simply right click the request and select “Copy as cURL”. Now your colleague can see the exact response you are without going to the browser.
We are proud to introduce React Serial Forms, a module which makes creating forms in large and medium scale applications easier. Check it out here and please feel free to contribute!
We even put together a snazzy example to see it in action.
npm is an incredibly handy development tool. Allowing for breaking your projects up into separate modules keeps logic isolated, maintainable and composable – especially when working with a larger team. When working with proprietary software, we can supply specific URLs in the package to lock down permissions and keep the code out of the public npm registry. However, this can cause a problem when working with portable docker images as the git clone will fail due to a missing id_rsa.
The solution we’re using is quite simple. Provide an ssh id_rsa file to authorize the clone. Instead of using your personal id_rsa, it’s much more appropriate to create one specific for the application and then add the id_rsa.pub as an authorized deploy hook in your git provider. This way you don’t have someone’s actual id_rsa floating around in repositories. Here are the steps:
The past few days I’ve been working a lot with Docker. As with many powerful tools, there are quite a few ways to get the job done. The most esoteric of them being how to persist data within Docker’s containers. From bind-mounting directories to your local system, to spinning up containers with only one purpose in life – storage. Here I’m going to be discussing and experimenting with a slightly different way of handling the issue: Controlled Persistence.
Quite a few of our projects are built on top of WordPress. One of the side effects to having a great community of developers behind the CMS is that there are updates almost every week for the core and some of the more popular plugins. Each of our projects is versioned using Git, naturally, so manually dealing with these updates can be quite tedious. So how can we make our lives easier? Well, a command-line script would be nice. There are a few of these that exist. From shell scripts to a fully fleshed out PHP WP package manager. The problem with these is that they are made to work in a similar way the built-in WordPress updater works – update on the server, thus making the staging/production code out of sync with the repository. These scripts also use the database itself to get information about the website via the wp-config.php script. What if you don’t have a local database setup for the project?
This is the reason we wrote this little bash script which handles updating the core and all plugins without the need for a database, wp-config file or a domain name in one fell swoop. Checkout the open source project here on GitHub for more information.
So you just finished developing your node.js application and you’re ready for the world to use it. Congrats. Now it’s time to decide how to host the application. In many cases you would use a turnkey cloud solution like Heroku, OpenShift, or AppFog. These are great services, but what if you want to keep this in-house or you don’t want to shell out the dough for each resource separately? These costs can really add up, even with a non-resource intensive application. Today I’m going to talk about a production-ready boilerplate stack for serving node.js applications from a bare Linux (Ubuntu distro) install.
I’ve been maintaining the super simplistic Rye starter theme for WordPress for about 3 years now. Since the time it launched it has been the only theme I have used and recommended because of its minimalistic nature. While there has been some other very well built themes to come out since, I believe they all share the same problems:
The workflow in which developers work together is essential to the longevity and productivity of the team. Based on my experiences with various types of development setups (some more painful than others), I’d like to share what I feel has emerged as the most efficient setup for our team at Lev Interactive.
connect-static2x is middleware identical to connect’s native static() middleware except for the fact that it enables support for image resizing on the fly. After an image is processed, it’s saved in the same directory as the original so the next request is cached.