Jeremy Davis
Sitecore, C# and web development
Earlier this week, I got my first chance to take a look at the agenda for this year's SUGCON EU**1 (in Dublin next month), and a few things jumped out for me as things I probably want to watch at the event. Maybe they'd be of interest to you too?
Sometimes things you think you know turn out not to be right. I got bitten by this issue recently, and it seemed like something to write down. Because being wrong is fine, as long as you learn something...
There are certain "rules of programming" that I keep hearing about in my career. One that came up in an interesting work debate recently was "you should never use regular expressions to parse HTML". Don't get me wrong - there can be a lot of useful knowledge wrapped up in these rules, but should we always follow them to the letter? I think it's an interesting question...
I bumped into an interesting redirect-loop issue with a Sitecore instance sitting behind Azure Front Door recently. It's not a product I know a great deal about, so this seemed worth writing down in case I come across it again, or others bump into the same challenge. Turns out it wasn't a Sitecore-specific issue, but its definitely something which could affect other Sitecore sites...
There was a lot of interesting discussion at SUGCON NA and the MVP Summit towards the back-end of last year. I've got piles of notes I took about stuff that caught my attention over the course of those events. But out of all the sessions, one specific thing stuck out to me as a vision of our future as Sitecore developers. And it's a topic that's come up a few times in my conversations with people at work and in the general community. So it seemed like it was worth writing about...
The second idea on my "little things I'd meant to add to this blog for a while" list was reading time estimates. Like the reading progress indicator from before, this shouldn't be tricky, and in this case I wanted to write it down in case anyone else working with Statiq was interested in achieving something similar on their site.
I'd had the idea that I should add a "reading progress" indicator to my blog posts for a while now, and I finally got around to adding it the other weekend. What I'd assumed would be a five minute job had an interesting issue I thought I should document for others...
Time for the final part of my series on controlling a web browser. With code to load a browser, and the overarching State Machine to control it, this part finishes off with the code for some states to load a page and extract its markup. Plus a few conclusions...
Continuing from my previous post about firing up a browser in order to automate it, this post moves on to the overall pattern for how the browser can be controlled.
I bumped into an issue recently where I needed to write some code to scrape a bit of HTML. The usual .Net approach of using an
HttpClient
didn't work here - the web site in question made use of some client-side JavaScript to generate mark-up at runtime. So I needed a different approach to fetch the resulting HTML. A while back I'd written some code to
grab images of rendered HTML using the Chromium DevTools APIs, and I figured I could play a similar game here...
