    
|
|
|
There has been a lot of talk about productivity. There are even sites that are built specifically to tackle the “art of productivity”. It seems a little odd to me that productivity is an entire industry when the heart of productivity is action, or doing it now. There are books called, “Getting Things Done” or “Extreme Productivity” and programs that teach you all of the tools that you need to do something.
I argue that the only way to be productive is to write the first word, play the first note, write the first line of code, or create the first stroke of the paintbrush. Anything other than action is a stalling method.
The questions I ask myself are, “why is there a productivity industry?”, “why do we read productivity books or buy overly complex software to manage what we do, when we could just do it?”. I believe it has nothing to do with our desire to get things done. We all want to be productive, we all want to make things, and we all want the internal or intrinsic rewards associated with getting things done.
There are a few factors that make us want to look for ways to be productive rather than just doing the work:
There are a few things that influence our abilities to act, rather than to get better at “the art productivity”. First and foremost, you have to really want it. Any room for doubt, disbelief, or lack of passion, will leave you with time to fill with planning, stalling, and looking for techniques to be productive. If you want it bad enough, you’ll be dying to get started. If not, ask yourself why you’re there thinking about stalling.
I often tell people that happiness is building what you wish existed, the moment the inspiration hits. Find the part of the task that you want the most. If it’s something you truly want to do, you’ll find a way to make sure it gets done as quickly as possible.
Inspiration is the single most powerful form of energy we have as creative people. Webster’s defines inspiration as, “the process of being mentally stimulated to do or feel something, especially to do something creative”. It is inspiration that gives us what we need to start, but keeping that inspiration is what we need to keep our momentum.
Perpetual inspiration, or staying inspired, can be much more difficult that it looks. Getting inspired is a fairly simple thing to do in our industry because there is great work consistently flowing through our twitter streams, blogs, music and books. But staying inspired, now that’s a different story.
We’ve all heard the folklore of projects that were halfway done or the notebooks full of ideas sitting on the shelves. How can we avoid this? How can we get ourselves into a state of perpetual inspiration so that we can see our projects through?
One, I believe it starts with being open and honest with yourself about who you are and what you’re capable of. Secondly, I believe it requires that we establish milestones that are very close together so that we’re constantly shipping and getting peer validation of our work.
This keeps us moving and this gives us the momentum we need to be successful.
I’ve been in this game for a hot minute now, and I have to say that momentum is one of the most crucial aspects in deciding whether or not a project succeeds or fails. The momentum is built upon two notions: getting inspired and staying inspired. Accomplish these two things by keeping things moving forward and shipping as quickly and as often as you can until the project is done.
This may mean shipping something ultra-simple and mind-numbingly stripped down at first, but it’s an honest approach that keeps your momentum while allowing your customers to continually be involved in the quick evolution of your product.
That’s how you get things done. That’s true productivity, and it doesn’t even require software to disable your twitter or facebook feeds. Just build it.
Start with the first thing right now.
The post The Key to Being Productive appeared first on Treehouse Blog.
]]>|
|
In this article we’ll take a look at how we can better integrate Chrome DevTools into our Sass development workflow.
Here’s a peek of what we’ll be doing in this tutorial via an animated GIF:
On the left is a terminal and the Sublime text editor, and on the right is Chrome. Changes to the .scss file are being persisted to disk, which is reflected in Sublime, the Sass watch command is generating a new version of a CSS file when it detects changes to the Sass file, which is in turn picked up by DevTools and reflected onto the page.
So what are we trying to solve here? Why would we want a better workflow? Well, let’s review an example of debugging some Sass-generated CSS, given the following .scss file, which contains:
$myColor: green;
body {
.box {
color: $myColor;
}
}
And now the CSS, which is generated by the above Sass file, would look like this:
body .box {
color: green; }
Now we just need a little bit of HTML to apply our styling to:
<div class="box">Hello</div>
Ok, so far so good. Now we want to start designing and developing our page using Chrome DevTools. First we inspect the div with a class of box by right clicking on it and selecting Inspect Element. Then we can check out the styles pane, which shows a green value for the color property, a note on the filename it’s contained within, along with the line number that the selector appears on. Now here’s where the problem lies – the processed CSS does not follow, line for line, what the source .scss file looks like, which can have a negative impact on our development workflow.
In the image above, the left pane shows a source .scss file and the right side shows the processed version. (Note I’m using the SCSS bundle for syntax highlighting in Sublime Text)
DevTools then provides a link to the file and line number of the selector, highlighted in red above, which unsurprisingly links to the processed file (image below). This now acts as a limitation for editing the file within DevTools as we can’t benefit from file saving. For example, if we persist changes to the processed file, they’ll just be overwritten when Sass next runs.
In fact, we don’t even have a clear indication of what the corresponding line number is – of course, practically speaking, our above example is very simple and we can very quickly understand what line maps to what, by looking at the code. However in a larger .scss file, things can get trickier.
As you can see above, DevTools has no understanding of our .scss file, we can address this however by utilizing a DevTools and Sass workflow, which is what we’ll be looking at in this tutorial. To summarize, a lack of Sass support in the DevTools could mean:
.scss file in the sources panel is difficult as DevTools doesn’t recognize the extension as one which should be viewed.Important: Sass support is an experimental feature. Please keep in mind that, while it has been around for a while now, things may change. If they do, we’ll do our best to update this article, accordingly.
Now let’s navigate to about:flags in the omnibox, then find Enable Developer Tools experiments, enable it and restart Chrome.
The image below shows an experiments panel, you can reach this by clicking on the cogwheel at the bottom right corner of DevTools and clicking ‘Experiments‘, then check the box for Support for Sass.
After closing and opening DevTools, you can now go to the General menu item in the left sidebar of the settings window and navigate to the Sources section, from there, check ‘Enable source maps‘ and ‘Auto-reload CSS upon Sass save‘. The timeout can be left at the default value.
This tutorial uses the latest version of Sass (3.3.0 at the current time of this writing) as there is some initial support for source maps. Here’s how you can install Sass using Rubygems:
gem install sass --pre
We now need to tell Sass to compile our .scss files, using the following command:
sass --watch --scss --sourcemap styles.scss:styles.css
From above, the styles.scss is your source file and the styles.css is the processed file, which your HTML page would use. Here’s how you would link in the processed .css file:
<link rel="stylesheet" type="text/css" href="styles.css">
If you see something similar to the image below in your terminal:
…and you see a generated .map file, then, congratulations: Sass debugging is working! Here’s what those other command options are doing from the previous compile command:
--watch: Will watch for changes to the source .scss file and compile it as soon as it has detected a change.--scss: Will display what style of Sass we are using.--sourcemap: Will generate corresponding source map files.Now, having an understanding of source maps isn’t critical to follow along, however it’s certainly something worth reading about as it’s intended to help the development process. See below for a few resources on source maps:
Assuming all went well, opening up your page where Sass support is enabled in DevTools should allow for Sass debugging. The first thing to note is that the filename will show the corresponding .scss source file, which is useful, in addition to that, the line number correctly reflects the line number in our source file.
Clicking on the filename will take you right to the sources panel with the line corresponding to the selector in question highlighted.
Note: You now have a viewable Sass file right in your browser with syntax highlighting!
Ok, so finding the corresponding CSS selector from the Elements panel is cool, but what about CSS properties?
In the screenshot below, the Sources panel has highlighted the CSS property I was interested in, to get there I had Command-Clicked on the property from within the Elements panel. The fact that it has taken me to the line where the value was defined (rather than the line: property: $value;) is very powerful!
Note: Navigating to a CSS property in the sources panel from command clicking the property in the Elements panel is not specific to Sass, it can be achieved with regular CSS too.
Editing a Sass file is not much different than editing a regular CSS file, one thing we will need to do however is ensure DevTools knows where the .scss file is located at on the file system. From within the Sources panel, the left hand sidebar should have a Sources pane which displays the .scss file, right click it and choose Save as, then overwrite the existing .scss source file.
Because we checked ‘Auto-reload CSS upon Sass save‘ and because Sass is running in the terminal with the watch flag, changes are made pretty quickly and the DevTools are able to show us those changes.
Even mixins work as expected, pasting the following, in an almost empty .scss file within the sources panel results in the correct CSS being generated, which DevTools is able to reload from within a second.
@mixin button {
border: 2px solid green;
display: inline-block;
padding: 10px;
border-radius: 4px;
}
.box {
@include button;
}
As you can see in the image above, the left hand side shows the .scss source file, which is what we would make changes to, the right hand side shows the generated .css file which DevTools has picked up changes from (almost immediately thanks to the watch flag in the terminal)
Paul Irish gave a great talk at Fluent which had lots of juicy information on the Chrome DevTools, but also the use of Sass. Skip ahead to 5:30 for the Sass information.
Let’s go over some of the main points discussed in this tutorial:
.scss file, future saves (Command+S) should overwrite the file.As you can see, the development workflow with Sass is not perfect, but it’s definitely a lot better than what it used to be. As time goes on, DevTools will provide a more streamlined workflow for editing CSS files and bugs will be fixed! Any issues you do find can be raised as a bug at crbug.com.
Thanks for reading this article!
]]>Another chance to catch the most interesting, and important, articles from the previous week on MIT Technology Review.
]]>|
|
Got a great idea for a site, but don’t know how to create a WordPress theme? Maybe you’ve already built a site but your client wants a CMS and you’re not sure where to start. Or perhaps you know exactly how to theme WordPress, but you don’t have time to track down what’s causing that bug.
If any of these scenarios sounds like you, then we’ve got a great competition for you: 10 lucky winners will receive $100 of credit to spend with CodeInWP which you can use for PSD/HTML to WordPress conversions.
CodeInWP are specialists in PSD or HTML to WordPress conversions. All you need do is provide them with the design in a PSD file or an HTML file and they’ll convert it to a responsive WordPress theme for you. They can even upload and configure the theme to your server.
They’re a team of over 10 coders located in Bucharest, Romania with over three years of experience in developing custom WordPress themes. They use the latest coding technologies for these conversions and can handle retina ready sites, parallax scrolling, media queries and anything else you can think of. While they may not be the cheapest option in the market, they choose to focus on quality work. They also offer psd to html and psd to newsletter on dotmarkup.com and newsletterize.com
“CodeInWp works wonders for my company. They do awesome work! I have no problem writing a recommendation for them, they have been involved in a project I have worked on and deliver excellent results. Our theme was quite complex requiring much back and forth. Excellent communication. Delivered what was requested. Allowed for testing and updates. You are in safe and capable hands with this team!” – Alex Roman
“Ionut and his team are wonderful people. They keep working until their client is 100% satisfied with the end result, even if this means that extra work needs to be done. They even work live on site while doing Skype and screen sharing sessions. I’m absolutely positive about their service and would wholehartedly recommend them for any WordPress job. Thanks guys!” - Stefan van Vliet
Win $1000 worth of psd/html to wordpress services – http://t.co/np4oNHPqQ9
— PSD to WordPress (@codeinwp) June 20, 2013
By entering, you get a chance to win 1 of 10 vouchers worth $100 each to spend at CodeInWP, on any WordPress conversion or service, including tutoring, conversion, fixes, technical reviews, etc.
Results will be announced here on WDD. All winners will also be contacted by email. Results will be announced on June 28th, 2013. Good luck to everyone!
| Symbolicons: 1,000+ Professional, High-Quality Icons – only $35! |  |
|
|
Page added by Cory Ziegenfuss
To find out if you are required to file a tax return, you may contact the IRS or a tax preparer.
Was this helpful? Yes | No | Correct or Suggest an Article | Request Help
Page edited by Andrea Mocko
Typically when these items are requested, we also request the Independent or Dependent Verification Worksheet. At the bottom of the form in the Tax Filing Status section, check the box that says you worked but were not required to file and attach a copy of all of your W-2s.
Was this helpful? Yes | No | Correct or Suggest an Article | Request Help