Motivation, Code, & Stuff

What Marionette Gets Right

![Ocean shore](https://images.unsplash.com/photo-1451186859696-371d9477be93) [Photo by NASA via Unsplash](https://unsplash.com/nasa) <br> 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. <br> ####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. <br> ####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. <br> ####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! <br> 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. <br> #### 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. <br> 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.

javascript marionette backbone

Readable Breakpoints

![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**.

sass media queries

Email Tooling

![Image of boarded windows](https://images.unsplash.com/reserve/Mj7V8XkOQLqVOyeXxixu_fierari-boardedwindows.jpg?ixlib=rb-0.3.5&q=80&fm=jpg&crop=entropy&w=1080&fit=max&s=200ba5409934114f394fa5ebff77ea19) [Photo by Leeroy, Unsplash](https://unsplash.com/leeroy) <br> 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**! <br> ####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. <br> ####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! <br> ####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. <br> ####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. <br> ####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. <br> ####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/) <br> 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).

email front-end

Run Towards Pain

![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=1080&fit=max&s=3ce7eb96ba1361d5cc20f9856f81c5cd) [Photo by Stefan Kunze](https://unsplash.com/stefankunze) <br> "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 brainfuck. But let's pretend in some sadistic alternate world, Google was built on brainfuck and you got a job offer paying you more money than you could dream of! You're job is to learn brainfuck. Would you do it? Most would say no, and understandably so. I would ask myself: if Google went under will having knowledge of brainfuck 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 brainfuck. So is everything meaningful in life. <br> ####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.

motivation journey html emails

Thanks for the cut

![tools](https://images.unsplash.com/reserve/oIpwxeeSPy1cnwYpqJ1w_Dufer%20Collateral%20test.jpg?crop=entropy&fit=crop&fm=jpg&h=800&ixjsv=2.1.0&ixlib=rb-0.3.5&q=80&w=1450) [Photo by Todd Quackenbush, Unsplash](https://unsplash.com/toddquackenbush) <br> By random chance, I met [Sean Callan](https://www.linkedin.com/in/seandcallan), a 15+ year software vet. He was kind enough to let me ask him a few questions. These are great tips I got from him. <br><br> #### 1. Review your own PRs Don't just look at it, but make comments on it. Like notes notes. Imagine the code was written by someone else. Comment on what sucks, what should the author improve upon. I did this yesterday and I saw a lot of room for improvement in my PR. Surprisingly more than I originally thought. In a start-up it's difficult to stop and review your code. It's always about getting features out quick and fast so we can be the first to market. But that isn't sustainable or responsible. You have to stop and review your code, it's just a part of writing software. Much like committing to git. <br> #### 2. Monthly Reviews What have you done in the past 6 months? What have you do in the past 2 months? What could you have done better? This is a great way of celebrating your wins and pointing out your weak spots. The goal isn't to bring these things into light and let them sit there, rather to learn from them. Great I'm getting better at CSS, but man my HTML knowledge sucks. Ok let's work in some HTML exercises next month. How can I show off my CSS strength? I always liked getting reviews from my manager because I saw it as a path to improvement. I like the idea of reviewing yourself, you have to be your own worst critic. Not that getting review from others isn't great either! I just don't have that luxury at this moment. <br> #### 3. Interviews sucks: practice problems Interviews are awkward, difficult, and confusing for both parties. I have been fortunate enough to be on both sides of the table and both sides suck. Good, now lean in. What sucks about interviews? They're difficult, it's like speed dating, and you always feel like you didn't give the right impression. Let's break it down a bit. <br> **- It's difficult** Here in the Bay, interviews usually involve some kind of algorithm, or math or some really abstract problem. It's not because the interviewer is trying to be an asshole. They're trying to get you to a spot where you are not comfortable and then work from there. So how do you get better at being uncomfortable and working your way out? **Get uncomfortable!** Practice algorithms, practice things outside of web development, practice concurrency in Ruby, etc. You know your weak spots, jump in. I'm not saying practice algorithms for the sake of being an algorithm master. I'm saying practice being uncomfortable and work your way out. Whether it's learning a new framework, learning a new language or an algorithm. Get uncomfortable! <br> **- Speed Dating** Any interview, technical or not involves social skills. There are many articles and studies that show, social skills matter. It is true that people will often overlook lack of technical skill over great social skills. No one wants to work with a jerk, even if you're the smartest most talented person in the world. Get social. Ok but how do you do that? There are books! I learned how to improve my social skills when I ran my photography company. I went on the bus and tried to randomly spark conversation with others. I tried to be more engaged in conversations, tried to find a common ground with strangers. It's difficult and uncomfortable, which means if you go through it, you'll come out better than before. <br> **- Facing rejection** We face rejection everyday. No one is counting. It doesn't matter how many times you get rejected. Actually, it has an inverse effect. The more times you've been rejected the more successful you are. Pick any successful person you can think of and do some research on them. How many times have they been rejected? How many haters do they have out there trying to bring them down? Let me put it into perspective. Kim Kardashian, I'll admit I'm a hater. But I got to give it up to her. No matter how many people hate, no matter how many photoshop scandals come out and how many people are against her philosophy and mindset, she still goes out there and does her thing. What's her thing? Making millions with top brands of the world. I read the other day that Snapchat pays her millions of dollars to film her life. You don't get that kind of success without putting yourself out there and getting rejected. So how am I going to hate? I don't make millions, not even close. The kind of rejection she faces on the daily, no every minute, is beyond compare. I often get rejection from my cats and even that I hate. Got rejected? Good! Use that anger, that rage and turn it into motivation to get better. Prove your haters wrong! <br> #### 4. It's a marathon, not a sprint I looked at Sean's linkedin profile and he has years and years of experience. And although I hate comparing skill with time, there is an undeniable truth that Sean has spent time honing his skills. Although I might work on my skills on a daily basis and perhaps more so than my peers, I have to always remember that it will take time for me to get better. I can't just read read read, pop my head up and say yep, I know stuff, give me a pay raise! It's going to take time and dedication. I have to keep on my schedule and grow and grow and grow. I can't just read one book and think, boom! I made it. When you are feeling frustrated that you're not where you want to be. Work towards that goal and remember it's going to take some time. And by time I don't mean sitting around and waiting, but you're going to have to do exercises, and do exercises and fail, and then do more exercises. <br> #### 5. Criticism is great advice Et says it better than I ever can. [ET inspires](http://etinspires.com/wp-content/uploads/2013/11/11.-Shine-Bright.mp3). >Everybody wants to shine bright like a diamond, but nobody wants to get cut.

journey-to-greatness tips eric thomas