Positioning an element on a web page can be tricky. You can specify the position of an element using left, right, top and bottom properties. But these properties will not work if the position value is not properly set. The positioning properties also display differently depending on the positioning value.
Many people know about services that allow you to ping your website to be sure it’s always online. The idea behind those is that they check every 5/10 mins sending a GET request to the given website and if they get an answer 200 they send you an email.
While going through a set of configurations to connect on a remote machine I was asked to upload my public key and I realized that I didn’t really know what that was for. If you are asking yourself the same question, or need to convince your mom she can safely use her credit card online, here is brief summary of what’s going on behind the curtains.
Recently Grio’s design team has adopted Lean UX that enabled us to expand our design toolbox in the following ways:
- Conduct in-depth Discovery and Research to define the products
- Inject a user-centric design focus
- Incorporate “deep collaboration” internally, as well as with our clients
In case you haven’t yet heard of it yet, Elixir is a functional programming language (technically, a collection of macros) written in Erlang. I have been persuaded to add it to my (and, consequently, Grio’s) technical repertoire due to a good amount of recent buzz in the blogosphere (as well as some points I’ll get to later). To make sure I have a strong foundation for my Elixir learning experience, I am starting my adventure with a foray into the underlying syntax of Erlang.
Grio Design is showing some blog love this week! We’ve been busy making clients happy by solving wicked design problems and producing beautiful interfaces, but I wanted to take some time to talk about user experience design (UX), usability, and how UserTesting can help everyone reap the benefits of usability testing.
For the past year, I’ve been working mainly with AngularJS and before that Ruby on Rails. I’ve never heard of Meteor until a few weeks ago. I am intrigued by the idea of tightly connecting the client and server together in a synergistic manner that allows for fast responsiveness, which is what Meteor is all about. I decided to go through Meteor’s tutorial online and get a feel for why the framework differentiates itself from other current technologies. From a very high level perspective, Meteor is a very good solution for quickly building an application from the ground up and provides some cool features out of the box.
It is a new year and I can exploit that to write a post proclaiming how
something ought to be done in 2015. We can use the new year to discard last year’s practices and mistakes as “the old way” and start fresh from lessons that we’ve learned.
The interesting (and also most frustrating) part about building frontend apps is
how fast the landscape changes. The tools, libraries, and frameworks that you
use today might not be the same as what you’d end up using on a new project only
a month from now. While we’ve ended up with this culture of adopting something
new as soon as someone posts that the “old” way is “dead”, I’ve found a few
pieces of the frontend stack that I do not plan on switching out anytime soon.
I would also like to preface this with stating that this post is highly
opinionated. The opinions expressed here are mine and formed through my own
experiences. These opinions may not reflect what I end up doing in practice, nor
does it reflect on what others at Grio may choose or use.
Continuous Integration at Grio
In the same way that testing code is more and more becoming table stakes for modern software projects, continuous integration is increasingly becoming standard on projects of any non-trivial degree of complexity. Here at Grio, we leverage continuous integration whenever possible, in order to eliminate time spent performing routine deployments and tracking down integration issues.
On a recent project I was tasked with creating a private CocoaPod to be used by several internal iOS applications. As I did my research to do this, I found that the information was spread across several sites and not 100% clear (the CocoaPods site’s documentation could use some love in places). I am taking this opportunity to assist those that follow to create, organize, test and distribute a private Pod. I’ll also throw in a few tips for general pod development.