Out of Sync

journey lesson

![Journals](https://images.unsplash.com/photo-1453574487790-de3ecc4ffc4a?ixlib=rb-0.3.5&q=80&fm=jpg&crop=entropy&w=1080&fit=max&s=ec098d8f8a865c5a4cfc6bbaccc94503) [Photo by Rodion Kutsaev via unsplash](https://unsplash.com/frostroomhead) Since getting back from my vacation, I haven't been able to get back to my daily routine and therefore have been less productive. I noticed having a routine helps me automatically say, okay today I'm working on xyz rather than searching for something to work on, and then getting distracted with twitter / facebook. There are days facebook is awesome, because it provides a great resource for connecting with others and staying in touch with the world. But it's a black hole of 90% information that is really irrelevant and more entertaining than thoughtful. #### Call to Action. - stop checking up on facebook, you'll learn nothing new - stop checking up on twitter, you've read most of the timeline - fallback to routine - watch coding youtube videos while eating For example I haven't deployed any new code to this blog nor have I worked on anything open sourced...yep time to fallback into the pocket. #### Lesson for the future It's absolutely necessary to take vacations. It reminds me of the people who are most important in my life and it keeps me motivated. But I need to set up a routine for vacations. What happens when I get back? How much time do I need to get my vacation madness out of me? How much of a break do I need from a vacation to fallback into routine.

What Marionette Gets Right

javascript marionette backbone

![Ocean shore](https://images.unsplash.com/photo-1451186859696-371d9477be93?crop=entropy&fit=crop&fm=jpg&ixjsv=2.1.0&ixlib=rb-0.3.5&q=80&w=900) [Photo by NASA via Unsplash](https://unsplash.com/nasa) Marionette doesn't get everything right. I actually think it gets more things wrong than it does right. But what does get right gives developers a great framework to build off of. So what does it get right? **Views** and how to manage them. #### Backbone's ghosting problem New Backbone developers sometimes forget to `remove` children views resulting in ghost objects / views. If you're not familiar with ghost objects in JavaScript, I'd suggest reading up on them, also known as memory leaks. The gist is if there is a container view which has sub-views and it gets removed without removing the child views individually, you have created ghost objects. Confusing I know, I'll queue it as another blog post. #### Layout View Applications typically have a top level view that manages all the components of the page. It dictates where the views will render and when to switch out the entire layout. Marionette's Layout View does a terrific job of separating different regions. So it's easy to render a side-panel with controls that affect a list of items in another region. I often use a Layout View for complex components as well. #### Collection View / Composite View Have a collection and need to render all of the models? Cool, Marionette has a view for that! All you need to do is define `ChildView` on the CollectionView and it will render all the models in it's collection, and even better, keeps them in order when sorted etc. Need to have some html around your list? Composite View can do that for you! What's nice about these views is that you don't have to worry about managing your children view. When you remove a Marionette View you can safely assume that it will clean up it's children views. What I don't like about these views is that I **have** to use Marionette's ItemView. I can't just use a vanilla Backbone View. It's an inconvenience but nothing more. #### Data Model Structure Because Marionette Views expect models / collections to have certain structure, it forces you to design your data model to the way it expects. What's nice about this is that it enforces a design guide to new developers. They are forced to follow the way the app is built not via code reviews, but by the code itself. Think Rails way or fight the framework to get it to do your way...maybe. Overall I think Marionette provides a great bootstrap platform to get Backbone projects off the ground. If I were writing a new application for long-term, I probably wouldn't install Marionette because I would only use a small percentage of what the library offers. But successful projects never start out with the intention of being around forever.

Readable Breakpoints

sass media queries

![Mushroom photo](https://images.unsplash.com/photo-1430933964450-0aefb85717c8?ixlib=rb-0.3.5&q=80&fm=jpg&crop=entropy&w=1080&fit=max&s=c859f1c36273cc589ec0ade5197e9120) [Photo by Manuel Barroso Parejo](http://www.domestika.org/es/lute3d/portfolio) <br> Using css media queries can be confusing. `min-width` takes me a while to process. When rather `<desktop` is super clear in what it reads. Welp someone went out and made that a reality: [include media](https://github.com/eduardoboucas/include-media). What's even better is that this project does not add bloat to your css, but just gives you an awesome sass mixin that allows you to do: ```sass .container { width: 300px @include media(">phone") { width: 600px; } } ``` So where does phone come from? Sass 3.3 introduces maps. Allowing for: ```sass $breakpoint: (phone: 330px, tablet: 720px, desktop: 1024px); ``` And thats it! Include media also allows for on the fly measurments like: ```sass .container { background-color: green; @include media(">500px", "<=1000px") { background-color: red; } } ``` That reads: container has a green background, red when screen size is between 501px-1000px. Way easier to read! I encourage you to try it out! Include Media **requires Sass 3.3**.

Email Tooling

email front-end

![Image of boarded windows](https://images.unsplash.com/reserve/Mj7V8XkOQLqVOyeXxixu_fierari-boardedwindows.jpg?crop=entropy&fit=crop&fm=jpg&ixjsv=2.1.0&ixlib=rb-0.3.5&q=80&w=900) [Photo by Leeroy, Unsplash](https://unsplash.com/leeroy) For the last week I have been doing nothing but reading up on emails and trying to build tooling around making my dev cycle shorter. Basically what I'm trying to do is make a static HTML site with constraints ( no divs / p / margins, etc ) but also be viewable in multiple environments ( ios, android, outlook, yahoo, gmail etc). Oh and **no javascript**! #### HTML Email clients **DO NOT** follow HTML5 standards. The only tags that seem to work on most clients, the dreaded `table` tag. DUN DUN DUN. Well actually it's not too bad, you just have to readjust how you approach building html pages. It's like knowing how to build a web server with Rails and then going on to learning Django. It's a different means to an end. [TutsPlus](http://webdesign.tutsplus.com/series/mastering-html-email--webdesign-17696) has an **amazing** series of tutorials. It covers a lot of clients and edge cases and by far the most comprehensive set of tutorial I've come across. Your HTML code is going to look HORRIFIC because of all the tables. To just center hello world in a red section you need a `table tr td`. That's 3 freaking tags for one section! Use templates / partials! I used [ejs](https://github.com/tj/ejs) to take a huge html file and break it apart into separate partials. #### Styles Emails need inline-styles, because some clients ignore style tags / header styles. Let [Juice](https://github.com/Automattic/juice) be your friend. Juice will take your stylesheet and header styles and inline all of your styles for you. Compile sass into css, run the HTML file, with a reference to my newly create css stylesheet, through juice and tada, inline-styles! #### Testing [Litmus](litmus.com) is the go to place for checking out how your emails will look on different clients. Their ideal case is to receive a test email, which means sending up your page as an email to a test account on litmus. No problem boss! I used [Mandrill](https://mandrillapp.com/api/docs/index.nodejs.html) to send out emails from my gulp eco-system. Mainly because we already had a Mandrill account, I'm sure it's just as easy with Sendgrid or whatever email service you use. #### Images So images work in an interesting way. You have 3 options. 1. Point image tags to an outside url . 2. Attach your images to the email itself and reference them via cid ( see [TutsPlus](http://webdesign.tutsplus.com/series/mastering-html-email--webdesign-17696) tutorial and [Mandrill docs](https://mandrillapp.com/api/docs/index.nodejs.html) on how to do this ). 3. convert your image into a base64 representation and inline it with your image tag. I couldn't use the last option because our emails are heavy content wise and I didn't want the src tags to count towards our character count (not verified). Yes there is a limit on how many characters your email can have before clients start clipping it. Email acid wrote an excellent [blog post](https://www.emailonacid.com/blog/article/email-development/gmail_ios_app_email_clipping) about it. I really don't know which of the first two options work well. I tested both on litmus and both seem to render ok. There are different methods because obviously it'd be too easy if one of the methods worked across the board, hint: they don't. #### Templating CMS I'm not the content creator for our emails by any means. And building out a cms to configure and edit an email newsletter is quite a bit of dev work. [MailChimp](www.mailchimp.com) tries to alleviate some of that pain by allowing you to copy / paste a html code with certain tags that are `editable`. Check out their [docs](http://templates.mailchimp.com/getting-started/template-language/) for a better idea of what it can do. It's a little bit limiting and the CMS can be buggy, but it's certainly promising and if you can make a few adjustments I believe you can put something together that will work for you. #### TLDR: tools **Tutorials** * Best tutorials: [TutsPlus](http://webdesign.tutsplus.com/series/mastering-html-email--webdesign-17696) **HTMLS** - use templating engine because table tags get ugly fast! I use [ejs](https://github.com/tj/ejs) **Styles** - inline only! [Juice](https://github.com/Automattic/juice) it, juice it good! **Testing** - [Litmus](litmus.com) will render your emails in different clients. **NOTE** it takes screenshots of how the email renders on clients, it doesn't allow you to navigate as if you were looking at the device. **Email CMS** - [MailChimp](www.mailchimp.com), the [docs](http://templates.mailchimp.com/getting-started/template-language/) Email can be painful, but it's only because you haven't exercised your email making abilities! [Just do it.](http://www.kaoruk.com/posts/01-06-2016-run-towards-pain).

Run Towards Pain

motivation journey html emails

![Priest sitting alone in a church](https://images.unsplash.com/photo-1430747562296-5556d17a15a5?ixlib=rb-0.3.5&q=80&fm=jpg&crop=entropy&w=900&fit=max&s=3ce7eb96ba1361d5cc20f9856f81c5cd) [Photo by Stefan Kunze](https://unsplash.com/stefankunze) "We're switching our platform to email newsletters." Whoa, okay. The thought of working on email formatting is exactly what a fork scratching an empty plate sounds like: painful. HTML emails are a whole new world. Things don't work because there is **NO standard**. `div` doesn't work, `float` doesn't work, `margin` doesn't work, [the list](http://stackoverflow.com/questions/127498/what-guidelines-for-html-email-design-are-there) goes on and on. A lot of developers will complain and groan and perhaps even quit because it's too difficult. Good. That sounds like job security to me. <br> Yes, I will complain and yes it will be painful. But I'll get it done. I'll read through the tutorials, learn the hacks and get that stupid freaking email to look exactly like the design. And then change it all over again because we're A/B testing. That is the job of engineers. Our job is not "build cool shit you want to use". Our job is build a product of value. I'll build cool shit I want to use on my own time. This site, among other projects, is proof of that. <br> I have always told my mentees, do things others refuse to do, you will have a leg up on the competition. Going through [MakerSquare](http://www.makersquare.com/) I noticed folks were having a difficult time with JavaScript ( back when it was a Ruby & JavaScript school). I made it a point to understand it even more. It helped me ten-folds. While running my photography company, I learned a niche is nothing more than the unwillingness of others. For example sanitation workers, [Heroku](https://www.heroku.com), [Medium](https://www.medium.com), baby portraits. > Do things others refuse to do. The balance is **value**. Do people *want* what everyone else refuses to do? Few people see the value of learning brain#&$!. But let's pretend in some sadistic alternate world, Google was built on brain$*@! and you got a job offer paying you more money than you could dream of! You're job is to learn brain$*@$. Would you do it? Most would say no, and understandably so. I would ask myself: if Google went under will having knowledge of brain$*@! give me a competitive edge? If the answer is yes, when do I start?. Look at it this way, someone is paying you to learn a new skill that will make you more valuable in your field. That's like **getting paid to go to college**. So what if you fail? You go back to where you started, except richer and more experienced. Why wouldn't you do it? Cause it's difficult, it's painful, it's a brain$*(#. So is everything meaningful in life. #### HTML email resources: I plan on writing about my learnings on HTML emails. Right now I'm still trying to get a good grasp. Here are some awesome resources I've found thus far: - [Mastering HTML emails tuturial](http://webdesign.tutsplus.com/series/mastering-html-email--webdesign-17696) - series of tutorials from [tutsplus](http://tutsplus.com/) - [List of unsupported HTML standards](http://stackoverflow.com/questions/127498/what-guidelines-for-html-email-design-are-there) - Stackoverflow Q&A - [PutsMail](https://putsmail.com/) - test your email template via copy paste. - [Litmus](https://litmus.com/) - **pay** for all-in one service. Similar to [Browserstack](https://www.browserstack.com/) for emails with other awesome features like analytics.