I think the big number 1 that trumps all others when building a person website is: focus on writing content.
This is by far the hardest part. All the other stuff: it's just tangential. Wordpress, Blogger, Jekyll, Hugo, Medium, hand-written HTML files: IMHO it doesn't really matter if you don't have any content. Just use whatever is easiest to get started with and gets out of your way when writing. For me, personally, it would be writing Markdown in Vim and converting that. For other people, it's something else.
Later, when you actually have some content going you can start focusing on tooling, layout, and so forth. Converting things to another platform usually isn't too hard. But chances are, you will never actually get any content going. I've seen a lot of people create personal websites, write one or two things on it, and then basically don't do anything with it.
I've built some websites for various friends/non-profits over the years, and about 90% of the time they never actually wrote any content. These days I ask people to write content first, and then I'll build the website for them. Most of the time I never hear about it again. That's okay, it's really hard to write content and a lot of people (myself included, before I had more experience with this sort of thing) tend to be way too optimistic about it and underestimate just how hard this can be.
And people will read your website regardless if your content is good. Is Paul Graham's website the peak of web design? Not really. People still read it. Dan Luu's website? Pretty much the most basic HTML file you can get. Still widely read.
That being said, if your goal is also to learn more if you're young or inexperienced: then sure, muck around with these tools all you want. I learned a lot from building my personal website over the years in all sorts of tools (geocities, hand-written HTML, shell scripts, PHP, Python, PHP again but this time with MongoDB, back to shell script, and finally settled Jekyll) and for much of this time I didn't have a lot of content. That was okay, because I learned a lot from the process.
Seems to be a lot of questions about how bootstrapped startups handle customer support.
I'm the cofounder of Eureka Surveys. We're bootstrapped, profitable, and just crossed 1M+ users. We've had an amazing experience hiring customer support in the Philippines. I have a thread about it on Twitter: https://twitter.com/t0mstah/status/1356296043009253382
The tl;dr is that you can hire cheap ($3.50/hr), high quality virtual assistants from the Philippines to handle customer support for you, all from day one. Having CS has really made a difference for us in our business and is one of our main differentiators as we've scaled up the CS team. DM me on Twitter and I can connect you to some excellent VAs looking for jobs!
I've implemented something very similar at work, this was a nice write-up. Biggest differences we're doing is to use Welford's algorithm[0] to calculate a running variance, so we can calculate anomalies in real time, without the need to store logs. It works quite well.
Sure. First of all, I want to say that backprop, by which I mean reverse-mode differentiation for computing gradients, combined with gradient descent for updating parameters, is pretty great. In a sense it's the last thing we should be trying to replace, since pretty much the whole deep learning revolution was about replacing hand-designed functions with ones that can be optimized in this way.
Reverse-mode differentiation has about the same time cost as whatever function you're optimizing, no matter how many parameters you need gradients for. This which is about as good as one could hope for, and is what lets it scale to billions of parameters.
The main downside of reverse-mode differentiation (and one of the reasons it's biologically implausible) is that it requires storing all the intermediate numbers that were computed when evaluating the function on the forward pass. So its memory cost grows with the complexity of the function being optimized.
So the main practical problem with reverse-mode differentiation + gradient descent is the memory requirement, and much of the research presented in the workshop is about ways to get around this. A few of the major approaches are:
1) Only storing a subset of the forward activations, to get noisier gradients at less memory cost. This is what the "Randomized Automatic Differentiation" paper does. You can also save memory and get exact gradients if you re-construct the activations as you need them (called checkpointing), but this is slower.
2) Only training one layer at a time. This is what the "Layer-wise Learning" papers are doing. I suppose you could also say that this is what the "feedback alignment" papers are doing.
3) If the function being optimized is a fixed-point computation (such as an optimization), you can compute its gradient without needing to store any activations by using the implicit function theorem. This is what my talk was about.
4) Some other forms of sensitivity analysis (not exactly the same as computing gradients) can be done by just letting a dynamical system run for a little while. Barak Pearlmutter has some work on how he thinks this is what happens in slow-wave sleep to make our brains less prone to seizures when we're awake.
I'm missing a lot of relevant work, and again I don't even know all the work that was presented at this one workshop. But I hope this helps.
We got a blog on the storage system coming on Wednesday. It's a mashup of a Merkle DAG and a B-tree called a Prolly Tree. It comes from an open source package called Noms (https://github.com/attic-labs/noms).
The basic idea is you create a SIT tunnel device and assign it an IPv6 /64 composed of two parts:
1. A network prefix between 32 and 56 bits long. This prefix is the same for all machines in the network.
2. A subnet derived from the machine's IPv4 address, minus the netmask.
For example, if your IPv4 addresses are allocated from 192.168.1.0/24 and the machine has 192.168.1.155, then the network prefix should be 56 bits long (64 - (32 - 24)) and the machine's prefix is `xxxx:xxxx:xxxx:xx9B::/64`.
The Linux kernel knows how to wrap the IPv6 with IPv4 so it can route within your local network to any other machine with a similarly configured tunnel device. If you want to send packets to 192.168.1.200 then they get addressed to `xxxx:xxxx:xxxx:xxC8::1` or whatever, they'll transit the IPv4 network like normal, and on arrival the receiving machine's kernel will strip off the IPv4 wrapper and route the IPv6 locally.
How's this useful? Well, if each machine has a /64 prefix then each pod can be allocated an IPv6 within that prefix without coordinating with other machines. Let's say the pod gets `xxxx:xxxx:xxxx:xxC8::aaaa:bbbb:cccc`. Anything with a correctly configured tunnel and that pod IP can route it traffic, no proxy or iptables needed.
I am a huge fan of Observable and I think it has massive potential beyond visualizations. To me it's the holy grail of a development environment, there is no separation between development and output. There is no toolchain separating source and binary, infact, the binary is partially recomputed on changes.
On top, it is forkable for others to build upon. It support comments, its reactive. When I explain it to people I say its like a combination excel + vscode + google docs + github. There is nothing like it!
I been trying to see how far I can push it for non- visualization software. Turns out... pretty far....
I am so productive in Observable because there is no context switch between development, using the product and debugging, it's all just one thing. Amazing, utterly amazing. I hope the Observable team can accommodate my use cases, as its clearly not what they had in mind.
Grouparoo | Senior Full Stack Engineer - Founding Engineer | Full-Time | Remote - USA
Grouparoo (https://www.grouparoo.com/) is a venture-backed software company building the open-source framework for managing, syncing, and syndicating data between your app(s) and all the marketing and operations tools your company needs to run. Do you need to keep your product data (Postgres) in-sync with Hubspot, Marketo and Zendesk? Do you want to limit the PII that leaves your firewall but still build robust email-marketing cohorts to use in Mailchimp? Do you want to enable your Marketing team to experiment with new definitions of what “high LTV customers” are, and try new ways to re-engage them… without you needing to write any code? That’s what Grouparoo does.
As our first hire, you’ll be a Founding Engineer at Grouparoo. You will be responsible for helping to craft the roadmap, developing features, fixing bugs, and building products that make our customers happy. We are a small team, and so we are looking for generalist engineers who are interested in learning about a wide variety of tools and technologies rather than becoming experts in any one part of the stack. We connect many different APIs, databases, and vendors, so there’s always something new to learn.
I record with Screenflow. It is much simpler (read: slimmer feature set) than Camtasia as well as cheaper.
For as straightforward an application as recording a screen w/ voiceover, there aren't many bad options. Personally, what I like about Screenflow is that it is easy to record straight to a timeline. I.E. I do a take, it saves to the timeline in Screenflow, I cut out the pauses/mistakes/dead air, or split a clip to redo audio or video for a particular section. Once satisfied, I move onto recording the next chunk, it's quite streamlined compared to recording in one app and then editing in another.
Egghead.io has a few free resources for their instructors, I'd recommend checking them out for some practical tips.
"Generating Software Tests" (https://www.fuzzingbook.org/) is pretty great (independent of your programming language) - arguably a must read for anyone interested in software testing.
John Regehr (the author of the blog post) has written more great posts:
This is by far the hardest part. All the other stuff: it's just tangential. Wordpress, Blogger, Jekyll, Hugo, Medium, hand-written HTML files: IMHO it doesn't really matter if you don't have any content. Just use whatever is easiest to get started with and gets out of your way when writing. For me, personally, it would be writing Markdown in Vim and converting that. For other people, it's something else.
Later, when you actually have some content going you can start focusing on tooling, layout, and so forth. Converting things to another platform usually isn't too hard. But chances are, you will never actually get any content going. I've seen a lot of people create personal websites, write one or two things on it, and then basically don't do anything with it.
I've built some websites for various friends/non-profits over the years, and about 90% of the time they never actually wrote any content. These days I ask people to write content first, and then I'll build the website for them. Most of the time I never hear about it again. That's okay, it's really hard to write content and a lot of people (myself included, before I had more experience with this sort of thing) tend to be way too optimistic about it and underestimate just how hard this can be.
And people will read your website regardless if your content is good. Is Paul Graham's website the peak of web design? Not really. People still read it. Dan Luu's website? Pretty much the most basic HTML file you can get. Still widely read.
That being said, if your goal is also to learn more if you're young or inexperienced: then sure, muck around with these tools all you want. I learned a lot from building my personal website over the years in all sorts of tools (geocities, hand-written HTML, shell scripts, PHP, Python, PHP again but this time with MongoDB, back to shell script, and finally settled Jekyll) and for much of this time I didn't have a lot of content. That was okay, because I learned a lot from the process.