Hey @amie734jj as frankbreetz mentions below, there is a list of remote in tech companies. They linked to the GH repo but there is a front-end - https://remoteintech.company
Having a 2 second look at the demo, it looks like a lot of useful kit. But what makes this different to other software, or indeed compared to Shopify and the like?
Great point. The main difference is that Shopify is great at e-commerce but it stops there.
Stockor handles the entire supply chain from purchasing inventory to managing it and customer relations. You'd use Stockor to manage all your business processes behind the scenes.
Now that stocker's open-source I'd expect someone to write a shopify adapter for it. I've got an Amazon one already written that I'll be releasing soon.
You never used Dreamweaver in your life. It has a great template system which make it easy to generate static websites, live inspection with an embedded webkit engine , and a very good style manager. Dreamweaver is definetly productive when it comes to integration or prototyping.
I started with DW back in 1999 as a crutch while I learned markup and styling. Gradually phasing out the visual editor over the years I got so accustomed to the code editor (highlighting/shortcuts) that I still use (and prefer) it.
DW got/gets a bad name because of it's visual editor (and therefore lower bar of entry) but it's no better/worse than any other visual editor.
right click open in new tab takes you to the original link. So this must be done in session or something and the alt-open in next tab take the plain link URL?
By doing right-click and "Open link in new tab", there's no actual onclick event, as what you're actually doing is opening the original link in a new tab. Therefore, his href replacing code wouldn't get executed.
"When I discovered that the popular web development tool PHP has almost complete ignorance of character encoding issues, blithely using 8 bits for characters, making it darn near impossible to develop good international web applications, I thought, enough is enough."
This is FUD. It's really not difficult to use the mb_* family of functions to deal with unicode in PHP. If you're writing a new app, this is trivial. If you're working with an existing app, it's obviously more difficult, but far, far from impossible.
Of course you can manipulate utf-8 in PHP, else it would have died long ago. But as a matter of fact PHP 6 was a failure, and unicode is still an afterthought that you must hack around with special functions in PHP5.
Well, there's almost no string handling built-in to PHP as a language at all, it's just provided as part of the standard library. So instead of using one part of the library (the standard string functions), you use another (the mb_* string functions.) I don't really see how that's a hack. The one thing that could go wrong is if you don't have the mb_* extension, but that's easily rectified, and hasn't been something I've seen in the wild in the past few years.
I'm not saying PHP's UTF-8 handling is great by any means, but the claim was that it's "nearly impossible." I'm suggesting that one should instead say "Building a UTF-8 compliant site in PHP is annoying, and requires more work than one would prefer, but if you do a bit of research, it's not that hard."
Because if you switch encoding you need to modify the code. All languages actually supporting utf-8 use the very same functions whatever the encoding is, eventually you simply need to declare that you're using utf-8 but that's all.
