Paul Phan's Articles on Cognitionhttps://cognition.happycog.com/feed
A blog by the folks at Happy Cogencontact@happycog.comCopyright 2020Thu, 30 Apr 2020 13:03:44 GMTThe “Cog” Filehttps://cognition.happycog.com/article/the-cog-file
Paul Phanhttps://cognition.happycog.com/article/the-cog-file#id:311#date:15:11On any given week, I might be working on 2-3 different projects at a time. I’ll often have to dip into an old project, start a new project, or assist another developer in their current project. When you’re dealing with so many files with so many different authors, you realize the importance of a well documented and updated README file. Every project has its own requirements, installation processes, coding styles, content management system, etc. A well documented README file can save a developer hours of time.

A few weeks ago, I ran into a situation where I had to pull in another a developer to help me finish up some work before an upcoming milestone. I directed her to our repository and she had the project up and running in a few minutes. I was excited by how quickly and easily she was able to get the project started, thanks to our internal documentation. I’ve lived through three hour `npm install` debugging sessions before where versions aren’t documented or dependency conflicts arise. This validated the importance of documenting every project setup. Saving time here allowed me to focus on my current work instead of wasting both of our time trying to spin up the project locally on her machine.

The Cog Commands

In terminal, Running `cog` will print a list of available commands we have available for this django app.
These commands can vary from project to project.

Whether the project is built with Django, Laravel, CraftCMS, Patternlab, or any other framework/cms, running `cog setup` will initially configure the entire project. This will install all the required packages, setup the local db, configuring your .env file, etc.

As of now, to automate our task we use either gulp or grunt. Sometime in the future we could be using who knows what. We can mask the default preprocessor by running `cog dev`.

The `cog go` command might be my favorite because with it we can start a docker container, run the built in PHP web server, or just about type of web server.

Invest the time

Not limited to the examples listed above, the cog file is a very powerful script. Instead of having lines of code to copy and paste to do all of these tasks, we compile it into one cohesive script. The time we invest into our documentation and cog files certainly benefits us as a team and saves us countless hours in the future. Do you have a different approach? How do you automate your workflow? Is your README file well-documented? I’d love to hear from you.

]]>TopicsgitscriptcogreadmebashThu, 15 Dec 2016 15:11 GMTCustom Attributes for our Spacing Classeshttps://cognition.happycog.com/article/custom-attributes-for-our-spacing-classes
Paul Phanhttps://cognition.happycog.com/article/custom-attributes-for-our-spacing-classes#id:303#date:15:30Recently here at Happy Cog, we’ve been using the lobotomized owl selector to handle vertical spacing between elements. Up until now, we’ve been adding a class of `.spacing` on a container to create equal spacing between all of its direct child elements.

While using this method on our projects, we noticed our class attribute was getting extremely cluttered with a variety of spacing classes on a single element. Here’s an example:

As you can see, there’s an overload of spacing-based class names littering the codebase. Scanning over this code with your text editor or devtools can become overwhelming. So how can we simplify this? Mark and I discussed a possible solution for this problem and came up with something like this:

We decided to use a custom attribute called `spacing` to separate our spacing classes from the stylistic classes. Our spacing classes only handle margin top while our stylistic classes set the background, borders, padding, etc. This ensures all the classes applied to an element are specifically for visual styling whereas any value in the spacing attribute is specifically for our vertical spacing throughout the project.

SCSS File

Here is a snippet of our .spacing.scss. We are using include-media to handle our media queries.

In this snippet, we are defining our spacing variables as well as setting our default CSS rulesets. we use a complex CSS selector to provide two collaborative, abilities. First, the ‘begins with’ selector is used to allow a default spacing to be set. Then using a wildcard match we can override that spacing on specific breakpoints using our custom `large()` syntax”. In some cases the spacing can vary from screen size to screen size. Following our default classes, we have a CSS ruleset to target spacing at different screen sizes.

Following the default spacing classes, we’re using CSS selectors to target any value in our attribute. If we don’t define `xsmall-xlarge` then it won’t be available. This is to keep the generated CSS size small and reduce extraneous code that we may never even use.

Putting it all together

The browser reads the example like this:

Give each direct child of the article element a margin-top of 14px on small screens and 20px on large screens.

For small to medium screens, give the direct child elements a margin top of 10px

On large screens give the direct child elements a margin-top of 60px

Some may ask, why aren’t you using “data-” to define your custom attribute? This is still up for discussion here on the development team. Sure, we might run into some issues further down the line, but that’s as easy as doing a `replace all` to fix our spacing attributes. We’re testing this method with one of our current projects and it’s going pretty smoothly. Does adding “data-” to our custom attribute really matter nowadays? I’d like to hear your opinions.

]]>custom attributeSpacingCodeTopicsWebThu, 29 Sep 2016 15:30 GMTThings I’ve Learned From Working With My First Web Teamhttps://cognition.happycog.com/article/things-ive-learned-from-working-with-my-first-web-team
Paul Phanhttps://cognition.happycog.com/article/things-ive-learned-from-working-with-my-first-web-team#id:250#date:17:36For the last 6 months or so, I’ve had the privilege of completing an internship working as a developer for Happy Cog. Throughout my time working here, I learned about the strategy, artifacts, and processes of building a beautiful, user-focused, responsive website. I attended both internal and client project meetings, worked directly with the designers and developers, and built an understanding of design systems and the best practices for coding.

I’ve been working on the web for about five years now, and have been a freelancer for two of those years. The beginning of my web career mostly started with doing work pro bono for local mom and pop shops and transitioned into learning how to interact with clients, branding myself, and finding new projects. I’ve mostly worked by myself when it comes to my web work, but in some cases I’ve had to work with a team on school assignments. As a freelancer, I set my own hours and schedule my day around my work. As I enter my first full time development job, I have to adjust to 8-hours of straight development and working with a team, which was a difficult transition to make. When I graduate in the summer of 2016, the experience that I’ve gained through my internship with Happy Cog is invaluable. As I finish up my internship here are a few key things I’ve learned from working with my first web team:

Don’t Be Afraid

Coming into my internship, I was extremely nervous and intimidated; it was all so new to me compared to my colleagues, who all have years of experience. Despite this, I’ve learned not to be afraid and to use their knowledge and experience to my advantage by speaking up and asking for help when I need it. The team is here to help and make sure you’re headed in the right direction. Utilize the helpful advice that you receive from your coworkers; don’t be afraid to ask why or how. Sure, you can find answers to anything by typing it into Google, but having that human face-to-face interaction can give you a level of understanding that the computer screen never could. It’s also good to keep in mind that the learning never stops on any experience level; not only have I learned from my colleagues, but I’ve even taught them a few things as well.

Clean Commented Code

Most of the work I’ve done has only been reviewed by me. I sometimes find myself slacking when it comes to keeping my code clean and well commented. I’ve always heard that it’s important, but sometimes I got lazy and careless. It wasn’t until I came to Happy Cog that I realized the true importance of clean, commented coding. In many instances during my internship, I’ve had someone review my code, handed off my work to another colleague, or even obtained someone else’s code; this has all shown me how important it is to keep my code clean. Always keep your code clean and commented so that your progress on a project can be well organized and run smoothly, especially in later stages.

Teamwork

Generally speaking, the majority of the work I’ve done previously was done entirely on my own. In a few circumstances, I was thrown into a group project and given specific roles, but here at Happy Cog teamwork is everything. Each person has their own specific role and can be working on multiple different projects. A website is a product of close collaboration between designers, developers, and project managers; any disconnect between any of these roles can cause issues throughout the process of completing the website. It’s important to be on the same page with the other people you’re working with, otherwise the site will be compromised. The relationship amongst your team is extremely important; at Happy Cog, there is constant communication between the members of a team as designers and developers work closely together to make the site the best it can be. With each project, designers and developers go above and beyond, working closely to make their designs possible. Keeping a constant communication not only increases the overall success of a project, but also brings a team closer together.

Adaptation

For years I’ve had a specific workflow, style, and structure when it came to my code. I was comfortable with the way I was doing things, and didn’t think to step outside this comfort zone. Then I came to Happy Cog, where i’ve had to learn how to adapt to a different culture and style of work; I was forced to step outside the box, where I had to learn to adapt to a different workflow and utilize that new style of development when it came to working on a project. As I finish up this internship, I can definitely say my entire mindset and workflow has broadened and changed for the better.

Be Prepared

Time management is something that is extremely important. As a freelancer, I usually only took on one project at time; I devoted all of my time and energy into that one project. During my internship however, I’ve had to take on different tasks on multiple different projects at a time. Adapting to this was overwhelming at first, but as soon as I got the hang of it, my workflow and process became easier and faster. I now come into work having an organized game plan to tackle all the different projects I have to work on.

Endless knowledge

One of the most important lessons I learned during my time with Happy Cog was to take the knowledge and skills that I’ve learned and to expand on them. I’ve learned a lot so far during my years at Drexel University, but I also came to find that there is endless knowledge out there on the web. There is no textbook that has everything you need to know in one place, where the web is constantly growing and changing every day, adapting to new styles and technique as the industry changes and grows. There is no one way of doing something, and there could be many different ways to approach and solve one specific problem. It is important to be up to date with the latest trends and to stay updated on our current standards by reading blogs, bookmarking sites, and expanding your knowledge by building and creating new things.

Document What You’ve Learned

Since day one, I’ve documented everything I’ve learned at this agency. I created a list of plugins, libraries, websites, blogs, services, and codes as resources to use on future projects. By sitting in on client meetings and design and code reviews, I have a better understanding on how I should approach a specific task or problem. A lot of the code I write is reusable, so when I complete something that I know can be reused, I usually keep my code saved on codepen.io in case I ever need it in the future.

In Conclusion

Reflecting back on everything I’ve experienced here over these past six months, I can definitely say that I’ve benefited a lot from this internship. Happy Cog has taught me a tremendous amount of valuable skills to carry on to my future work. I was able to work on a full project from start to finish during my time here, and surpassed even my own expectations. The main thing I’ve taken from this experience is learning the importance of stepping out of your comfort zone and pushing your own limits, and always to be open to trying new things.