In this post, I’m going to discuss the importance of enforcing a strict and clear coding standard in your Meteor applications, and then provide you with some tools that will make the process easy.
In this post, I will discuss the importance of implementing proper structure patterns in Meteor applications, and give some advice that may help you organize your codebase.
How many times have you been stuck on a difficult problem that required lots of debugging? Hours go by and you make incremental progress on the solution. Finally, eureka, you’ve cracked it. On to the pull request! To your dismay it gets shot down immediately because print statements. What if I told you you were doing it wrong?
Howdy perfers! In the US we’re gearing up for a long Thanksgiving weekend, so if you find yourself with some free time on your hands try digging into one of these awesome DevTools resources for mobile development.
It will come to no surprise to anybody who has heard me speak that I am no friend to Bootstrap. One of my goals with the trainings that Four Kitchens does for Responsive Web Design at various Drupal events and for companies, is to give developers the tools they need to not using Bootstrap or other similar tools. I hope to clear up why I feel that Bootstrap is the wrong tool for most websites, and what you can use instead of it.
When you are developing data models for fields in Drupal sometimes the only thing you can count on is that there will be exceptions to the model. Thankfully, with Drupal, you can incorporate a lot of flexibility into your data model. Typically that flexibility comes at the cost of complexity for you, the developer or site builder, and likely, for your content contributors. It gets even more difficult when those fields are irregular in format, need to be responsive, and are a part of a time sensitive content launch involving content experts with little to no Drupal experience.
Today I looked through my collection of links and realized I have enough resources pooled up to put together a decent little post on browser devtools. In case you’re not familiar, development tools ship with each web browser, enabling us to analyze and debug our increasingly complex websites and apps. From finding a background color to profiling frame rate issues, browser devtools bring sanity to the world of frontend development.
If you’re a follower of this blog or Four Kitchens in general you might have noticed that making the web accessible to mobile devices is something we’re interested in. One of the biggest challenges with mobile computing is unreliable network connections that are inevitably encountered in the wild. This is particularly troublesome when your website becomes more of a web application that should behave the same regardless of connection status.
I spent several hours last night just trying to add some configurable social sharing buttons to my node pane, but I needed to use fields from the node itself within my code. After hours of Google searching, and checking versions– I finally figured out how to do what I was looking for. Part of this confusion is due to just ctools (Chaos Tool Suite) having slightly different API depending on its version. Note, I am using ctools version 7.x-1.2 and panels version 7.x-3.3.
Anyone working with the Drupal theme layer knows that sometimes our frontend debugging is accompanied by some backend trouble as well. While this is manageable in some cases, other times you really need those error messages to go away so you can work on the theme.
Inspecting the element and deleting manually using browser devtools is tedious. Setting some development CSS is risky, because you might commit the change into your codebase. What’s a frontend dev to do?