Disqus - Latest Comments for philhawksworth

Re: Featured site: Nike - Just Do It

Phil Hawksworth — Fri, 01 Mar 2019 05:56:16 -0000

Then again, the move for such a large brand to begin embracing a hosting approach for their web properties which is not on their internally provisioned and maintain hosting environments is an interesting signal.

Regardless of the front-end implementation, the sight of Nike putting confidence in a stack and external hosting platform is encouraging for agility and performance in the future.

Re: What happens when packages go bad?

Phil Hawksworth — Sat, 15 Dec 2018 06:53:05 -0000

Interesting (and a little unsettling) observations in here!

You mentioned the option of running your local builds within a Docker container for the sake of sandboxing the code being executed away from your local development machine. On that note, since you are running your production builds for Squoosh within a build image on Netlify, you can use this exact same image in your local build if you wanted. It is open source and available to run locally in exactly the way you described.

Find it here, along with some docs:
https://github.com/netlify/...

Re: 3 of the Most Common Errors in React

Phil Hawksworth — Fri, 14 Dec 2018 08:25:17 -0000

Thanks for spotting those!
Fixed.

Re: Adding Your YouTube Videos to Your Static Site on Netlify

Phil Hawksworth — Wed, 08 Aug 2018 09:58:24 -0000

Thanks Raymond!

This is a nice example of a pattern I fnd myself leaning on quite often:

1. Request content from content feeds around the web
2. Stash content in a format friendly to your chosen SSG
3. Generate your site to include your gathered content via your templates

Having the ability to run a build script in Netlify, just as you would locally, opens this up nicely.

The example of mine that you referenced ultimately got replaced by Netlify's built-in form handling and API access to the submissions.

I updated it a little and added some notifications, and it turned into this example: https://css-tricks.com/jams...

But it all just uses the same pattern that you demonstrate so nicely here.

Re: Netlify Lambdas - As Simple As Possible

Phil Hawksworth — Wed, 09 May 2018 04:46:27 -0000

This is great. Thanks Mark!

One small modification I recommend is that you don't put your production ready lambdas inside your publish folder.

This will work just fine, but it also means that you are exposing your lambdas over the web as part of your public folder. People could technically browse to them (if they knew the URLs) and then see what is in your source.

Typically that's not a problem, but lambda functions are often useful for making calls to APIs and other things that might include secrets that you don't want to expose on the client-side. You'd potentially expose those secrets if you put them in your publish folder.

This is why Netlify allows you top define a different path to those functions. It can be anywhere in your project folder. Personally I like to define those things as:

publish = "dist"
functions = "functions"

Great explanation though. Thanks for sharing!

Re: Building a Serverless Lambda Function with Netlify

Phil Hawksworth — Tue, 13 Feb 2018 09:49:42 -0000

This is wonderful Alex! Thanks for publishing such a detailed walkthrough. I like the technique of grabbing values directly from the netlify.toml file in your build scripts. Handy.

You might find dotenv (https://www.npmjs.com/packa... useful for managing local environment variables. It lets you keep them secret and avoids committing them to your repo where people can discover them. It also means that you can access them in your code exactly the same way both locally, and when running the code in production where the environment variables are available. Saved me some pain in the past!

Re: Break through the limits of static site generators

Phil Hawksworth — Tue, 29 Sep 2015 08:49:04 -0000

Slides from this talk were posted here: https://speakerdeck.com/phi...

Re: Frontenders to Follow in 2014

Phil Hawksworth — Thu, 02 Jan 2014 07:40:51 -0000

Yeah... it's a bit cat heavy

Re: Weekend Presentation: Phil Hawksworth Can Smell Your CMS

Phil Hawksworth — Wed, 03 Apr 2013 13:01:07 -0000

Gareth,

I think that an important point is that often the users who are creating content are not designers (even though they like to tinker with design and feel creative, as you mentioned). The danger here is that systems can sometimes "give users the power to ruin their site", as Rachel Andrew puts it.

Constraints can sometimes be enablers since they force users to observe the designed content strategy and conventions. With large flexibility comes an inevitable attrition of the design and conventions over time. I like the suggestion below from Anthony, where he talks about avoiding large content blocks, and instead providing logical separate inputs for structured content.

Re: Weekend Presentation: Phil Hawksworth Can Smell Your CMS

Phil Hawksworth — Wed, 03 Apr 2013 12:52:21 -0000

Ian,

I agree. Rachel Andrew has some excellent talks on this topic and has some great insights from her work on Perch. I like her presentation from SmashingConf last year:

http://www.rachelandrew.co....

Brad Frost did a nice summary of her talk too:

http://bradfrostweb.com/blo...

Re: Using Pusher to Enable the Real Time Web

Phil Hawksworth — Wed, 09 May 2012 09:47:23 -0000

You can see a whistle-stop view of the MakeDay, including a quick view of the smiling faces of those using the "Tea Round" web app in this video: http://www.youtube.com/watc...

Re: Excessive Enhancement

Phil Hawksworth — Fri, 04 May 2012 05:07:19 -0000

Delighted to hear it, Julian!
...and regarding your non standard convention of "scroll to start", I agree with your UX bods. I guess then, the challenge is in how do we provide an affordance to that interaction so as to make it discoverable. Fiddly.https://twitter.com/julianpscheid/s...

Re: SXSW 2012 - Excessive Enhancement: JavaScript's dark side

Phil Hawksworth — Wed, 31 Aug 2011 13:03:00 -0000

Sure. But people who are experts in writing Javascript can also make bad decisions about designing and developing for the Web. I've been seduced by the latest Javascript whizzbang before. Casting an eye towards progressive enhancement is important, I'd argue.

Re: SXSW 2012 - Excessive Enhancement: JavaScript's dark side

Phil Hawksworth — Tue, 30 Aug 2011 07:45:24 -0000

Yes indeed. I'm a huge fan of Javascript and count myself as a Javascript developer. I'm keen to explore what aspects and trends of developing on the web with Javascript tempts developers into some bad practices.

Re: http://blog.tommorris.org/post/1407588225

Phil Hawksworth — Tue, 26 Oct 2010 18:37:13 -0000

Thanks for the shout out to The Team, Tom! I'm hoping that we can do much more work with Canonical since I'm a big fan.

Re: Leaping Forward

Phil Hawksworth — Fri, 26 Jun 2009 08:36:56 -0000

I watched this exchange as it happened and can see arguments on both sides.

For me, email is a text based medium. Keeping it as such gives us the best chance of interoperability. I don't compose emails in HTML or even rich text because you can never be sure of the capabilities of the recipients email client. So Chris, on a personal level, I'm with you there.

The problem is that assuming that everyone has the the power to choose their own email client is a little naive. Think of the huge numbers of people using the applications that they were given by their company IT department. Most people (sadly) simply don't get to choose and Outlook has a huge user base in companies and large enterprises where these things are tightly controlled.

To be honest, I personally don't really care if people receiving html emails don't get pages which don't look right or are broken. If html emails aren't reliable enough, perhaps people will send them less. The big issue for me is that there are loads of people (including our clients) who do care about this, and they write html so that it works where they need it to. Do we really want to educate people to write html to work in some half-baked, fugly, non-standard, pseudobrowser? I want there to be a rising tide in Web development which means putting naughty browsers (and html rendering engines) out to pasture and embracing Web standards.

Would the problem go away if nobody sent html email? Sure. But that's not going to happen anytime soon. There are just too many controlled environments where user choice isn't the deciding factor. I'm keen to develop Web sites which ignore the limitations of IE6 and simply tell users to upgrade, but I can't do that if I also need to serve people stuck over the wrong side of that impenetrable hedge. Turning a totally blind eye and hoping that it goes away can't be the right approach.

While html emails exist, I'd prefer that they did so in a way that didn't damage the Web and the quality of its developers.