If you are a software developer for Apple’s iOS platform you are still recovering from the latest announcements about the future of iOS. There is a lot to digest in regards to the big news for developers and we discuss a few notable highlights. Read more
To commemorate 40 years of Rubik’s Cube and support Google’s timely Doodle earlier this week celebrating Ernő Rubik’s iconic brainteaser, our Nerds worked with Google to help build Chrome Cube Lab with the intent of letting other devs use Google’s API to re-imagine Rubik’s Cube, and play with it in all new ways. Read more
In an awesome act of creative collaboration (and a lot of sweat), The Nerdery helped Google this morning to launch Chrome Cube Lab to honor the 40th anniversary of the Rubik’s Cube (see today’s timely Google doodle). Originally created by Ernő Rubik, the Rubik’s Cube is a logic puzzle that has been a favorite of engineers and mathematical types since its debut.
Programming, interactive media, and the web have come a long, long way. It’s humbling to realize nine years have passed since the Arduino introduced an affordable microcontroller to the public, or seven years since the original iPhone redefined our expectations of what a cell phone can be.
2014…another year of the internet, social media, home automation, video games, wearable tech, smart TVs, and multiple ecosystems of mobile applications running on a growing variety of phones and tablets. Maybe you’re developing an app or website or you know you need one…In an ocean of computers, browsers, and gadgets, how do you choose what to support? Support means testing and there’s simply too many options to test on every single phone, tablet, and browser.
Whether it be a website, native mobile application or web app, the environment you support defines the reach and intent of your presence online. Choosing the right platforms to support demonstrates a strong product vision, general technological awareness and long-term plan for the work. So, what is the right direction to aim? Read more
Facebook recently held their developer conference, F8, where they outlined a number of changes for how developers can build apps on their platform. This included changes to how developers ask for users’ data, a whole new login screen, and a few new features. Let’s examine the changes a bit more in depth and discuss how this could impact your site. Read more
At GDC (Game Developer Conference) 2014 earlier this year, we were bombarded with a series of announcements. All of the top players were showing off all of their new technologies and it was a pretty whirlwind week. One of the most promising announcements was the promise from Unity that their game engine Unity3D would have the ability to export to WebGL, which means that the content you create could run in modern browsers without the requirement of plug-in.
Before we get into the meat of that those statements, let’s get you up to speed on a couple of things. Read more
On April 8, 2014 WordPress released a security update to version 3.8.2. The announcement that accompanied the release states “this is an important security release for all previous versions and we strongly encourage you to update your sites immediately.”
WP 3.8.2 addresses two potentially serious security vulnerabilities, includes three security hardening changes, and addresses nine “other bugs.” Most notably the following security issues are addressed:
- Potential authentication cookie forgery. CVE-2014-0166. (Very serious vulnerability!)
Privilege escalation: prevent contributors from publishing posts. CVE-2014-0165.
Pass along additional information when processing pingbacks to help hosts identify potentially abusive requests.
Fix a low-impact SQL injection by trusted users.
Prevent possible cross-domain scripting through Plupload, the third-party library WordPress uses for uploading files.
Additionally: JetPack – the wordpress.com feature-rich plugin suite – was updated to version 2.9.3 to address similar issues.
If your site is currently operating a WordPress version below 3.8.2 or Jetpack version below 2.9.3, you may be at risk and should consider upgrading as soon as possible.
On Monday evening, a security firm announced a new vulnerability in a key internet technology that can result in the disclosure of user passwords. This vulnerability is widespread and affects more than two-thirds of the web servers on the planet including top-tier sites like Yahoo and Amazon. If you have a secure (https) website hosted on a Linux/Unix servers using Apache or Nginx or any other service using OpenSSL, you are likely vulnerable.
For a detailed breakdown of this vulnerability, please see this site. This security vulnerability may affect up to two-thirds of all web servers. We urge you to assess your vulnerability immediately, and reach out for help.
How can I get help to fix this problem?
- Contact The Nerdery
- Contact your hosting provider
How can I see if my servers are vulnerable?
You can use this site to test your domains for the vulnerability. Enter the domain of your HTTPS web site. If you get a red positive result, you are vulnerable.
In addition, you can execute the following command on your servers to see if they are running a vulnerable version of OpenSSL: openssl version -a
If the version returned is 1.0.1, and its build date is before April 7th, 2014, you are vulnerable.
How can I fix it if I am vulnerable?
You will need to obtain a patched version of OpenSSL and install it on all vulnerable servers. Updated packages should be available for Debian, RedHat, Ubuntu, and CentOS via their package managers. If a package is not available for your platform, you can recompile the OpenSSL package (version 1.0.1g) with the NO_HEARTBEAT flag, which will disable this vulnerability. After updating, restart any services that are using SSL and re-test your domain using the link above (http://filippo.io/Heartbleed/).
For information on your specific Linux distribution see:
- Debian: https://www.debian.org/security/2014/dsa-2896
- Ubuntu: http://www.ubuntu.com/usn/usn-2165-1/
- RedHat: https://access.redhat.com/site/announcements/781953
- CentOS: http://lists.centos.org/pipermail/centos-announce/2014-April/020249.html
Additionally, you should strongly consider changing passwords and/or resetting SSL certificates, but only after OpenSSL has been updated.
What is the vulnerability?
With the vulnerability, called Heartbleed, attackers can obtain sensitive information from servers running certain versions of OpenSSL. Examples of sensitive information include private encryption keys for SSL certificates, usernames/passwords, SSH private keys on those servers and more. Attackers which obtain the keys to your SSL certificates can then set up a man-in-the-middle attack between you and your customers and obtain secure information, such as credit card numbers and authentication credentials. The vulnerability was publicly disclosed Monday, 4/7/2014.
If you have any questions, please contact us, or ping your own go-to Nerdery contact right away. We’ll help analyze your risk and protect your data. If The Nerdery can be a resource to you in any way, we will.
What Are Dashicons
On December 1, 2013, WordPress 3.8 – code name “Parker” – was released. One of the highlights of 3.8 was the re-skin of the WordPress admin, officially called the Dashboard. The re-skin got rid of the blue, grey, and gradient interface for a more modern and flat design. Included in the update were Dashicons, an icon font.
An icon font has all the benefits of being text and none of the downsides of being an image. Size, color, and pretty much anything else you can do with CSS can be applied to icon fonts.
There are several ways to use Dashicons inside the Dashboard. For this example I’ll be using a plugin, but you don’t have to. If you’re more of a functions.php person, it will work there too. I’ll also be skipping over the details of customizing WordPress and focus on Dashicon-specific code.
Set Up Base Plugin
I already have the plugin created, uploaded, and activated. You can see the final plugin on Github. For each section, I’ll only be highlighting the relevant code. The code could be included in your own plugin or the functions.php file by using the appropriate hooks and filters.
“Quite often people think that maintenance is just finding and fixing bugs, but it’s more than that. It’s also about keeping things updated, about enhancing existing features, and it’s about building out new features. It’s about ensuring your site/software continues to evolve and grow instead of just standing still. In technology, you’re either getting better or you’re falling behind. Standing still isn’t an option.”
Software without maintenance is like buying a car with no budget for gas
Thinking of starting a maintenance program? Picking the right number of hours can make a big difference as to how your project works.
Types of Maintenance Budgets
I’ve done a number of maintenance programs and each one is a little different, however they fall into one of three buckets; no hours, few hours, lots of hours.
No Hours or Low Hours: If you choose to allocate no maintenance hours, meaning you just call when you want work done, or if you have very few hours, the main disadvantages you will encounter are loss of knowledge, access to specific developers, and an impacted timeline.
Maintenance planning that keeps a team together: Ideally, one developer would be on your project to help with all future fixes. Having a developer with background on the project, code, and familiarity with client relationship is beneficial. However, those developers are valuable. They will get assigned to another project if they aren’t busy and they will become unavailable for your unexpected project.
Proper planning will maintain development efficiencies: When you lose the developer, you also lose some of the knowledge. We’re still a team and still transfer knowledge form one developer to the next, but switching developers can reduce some efficiencies. We all do our best, but the new developer still has to learn all the ins-and-outs of the code.
And then there is timeline. If we can’t plan for your maintenance changes, you will have to wait until a developer becomes available. That could be a few days to a few weeks. It all depends on developer availability and the complexity of the changes.
Planning For Success – Keep The Bucket Full
If you have a good amount of hours in your maintenance bucket, it’s easier to keep a developer on the project, retain knowledge, and plan for the work.
I’ve been working with one client for about three years now and I continue to lead the maintenance project, which is supporting the sites that we created. Every time they ask for something I know the project history, I know what we’re talking about, and I know which developers actually built individual pieces of the site. Knowing all this makes it much easier to understand the request, estimate, and execute.
This client also has a good bucket of hours, which helps me plan for changes. I know that – based on the client budget per month – I need to spend X hours per week. Not only does this help me plan for development, but it also helps with setting expectations for the client. Our turnaround time on requests is usually a few days. We’ve gotten ourselves into a groove and it works well for the client and the rest of the team.
What’s a good number of hours?
That’s a good question.
- How many changes do you plan on having?
- Do you think you’ll have some minor changes and updates?
- Do you think you have some features you’d like developed during your maintenance program?
- Are you thinking of a handful of changes per month or do you have a long list already and it just keeps growing?
It all depends on how much work you want done each month and how fast you want to get things completed.
For example, if you’re thinking 40 hours a month, one developer can plan for about six hours per week. When other projects come up, that developer can safely plan for both projects. However, six hours per week also limits the amount of work the developer can get completed. More complex tasks may take a few weeks to complete.
Wait, six hours per week is only 24 hours a month. What about the other 16?
Where most maintenance plans might fall down – “Where’s the QA?”
Another thing to consider when setting up maintenance hours is that the hours are not all development hours. You have to have some time for project management and QA. There will be phone calls, and email communications, status reports, and we’ll want to run any change through QA to help ensure we didn’t fix one thing and break another.
Quite often people think that maintenance is just finding and fixing bugs, but it’s more than that. It’s also about keeping things updated, about enhancing existing features, and it’s about building out new features. It’s about ensuring your site/software continues to evolve and grow instead of just standing still. In technology, you’re either getting better or you’re falling behind. Standing still isn’t an option.