dpezely
Joined 16 years ago
Joined 16 years ago
"If you need to make a single cold call in the first 2-3 years, consider your network might be insufficient."
Such cold calls would include finding: co-founders, investors, customers, service providers, manufacturers, employees, etc.
Mind you-- I got this wrong in my own startup that didn't survive. Having advised founders and non-tech entrepreneurs in Seattle, SF and Vancouver and of those who heeded the advice, they succeeded where I didn't. E.g., when I had a co-founder flake on me, my network was insufficient to have another person I could trust to step in as subject matter advisor. Not that I would have expected that advisor to write code but perhaps to guide me through the principles of the niche topic such that I could then find the right contractor or employee.
Likewise, for some businesses including certain SaaS: picking your first customers carefully often requires a chain of trust in both directions; i.e., your network.
- 2003 edition: https://bookshop.org/books/burning-chrome-9780060539825/9780...
- 1986 edition: https://www.amazon.com/Burning-Chrome-William-October-Paperb...
Long-term, a combination of theirs and your own could be optimal.
There are strengths and weaknesses with using their dumps: on one hand, benefits include them having crawled and having dealt with being throttled, etc. They offer monthly dumps for general content and daily dumps for news [2].
On the other hand, it's a huge pile of data to wade through, and their index format might not be your preferred method. The archive and index reside officially at AWS, so that may decide where to process it. (Not sure whether other providers maintain a copy as well or not.)
By "huge", specifically:
> October 2020 [...] contains 2.71 billion web pages or 280 TiB of uncompressed content.
From our analysis a few years ago, that was to be the approach for the now-defunct Snagz.net [3] (which never fully launched because co-founders were unable to join due to extenuating circumstances).
[2] https://commoncrawl.org/2016/10/news-dataset-available/ - this one can be hard to find unless you know to look for it
[3] https://web.archive.org/web/20180320001756/http://snagz.net/
Also, contacting one of the people associated with a blog listed on Planet Lisp [2] would ensure that it appears there and might be seen by a wide yet relevant audience.
After having faced a similar learning curve, I put what I know into a lengthy document[0] written in 2018 based upon explorations over 2016-17. That will get you deployed and operational quickly by following just the final section. The first section explains key concepts using conventional ideas as the means of introducing NLP jargon. In between covers theory and practice for getting the most out of any tool you're likely to use in the end.
More general tools are probably available today, such as add-ons for Elasticsearch. I'd start looking there. Interesting items came up when searching ddg for: NLP elasticsearch.
[0] http://play.org/articles/introduction-to-natural-language-pr...
From your perspective, what are Clojure's prospects for contemporary and future alignment with the JVM?
After all, Rich Hickey built the core in 2006-07. Looking at his graph[0] of code introduction and retention in his HOPL-IV paper[1] might imply that either he's that good at the core abstractions or possibly the language could suffer a similar set of limitations as commented about Kotlin above.
[0] https://download.clojure.org/papers/clojure-hopl-iv-final.pd... p26
Also, their code base is minimal: does just enough with Rust shared library to have an app generate a log message. That's enough if you already know Android development.
For a complete end-to-end example search query screen with results screen (Activity, Fragment) using Rust, Kotlin, androidx, RecyclerView, ViewModel, etc., there's [2], but it was written while learning all things Android.
Perhaps it might help someone out there!
[1] https://medium.com/visly/rust-on-android-19f34a2fb43
[2] https://gitlab.com/dpezely/native-android-kotlin-rust
Edit: Yes, that second one is mine. Had fun learning but hopefully will never have to touch mobile dev again beyond maybe a PWA. (I'm a server-side dev.)
As someone just getting into Nix and NixOS myself, I found one particular comment there offers an excellent summary after talking with a few others in person as well: https://news.ycombinator.com/item?id=22891648
Essentially, after an initial investment of time for learning curve, the huge payoff comes when migrating to another machine because of system-wide configuration being reproduced with precision.
In my case, moving back and forth between laptop and desktop/workstation was a pain point with Xubuntu. A delta of less than one hour between `apt-get dist-upgrade` on two devices was enough to translate into divergence of versions in some packages.
We've come a long way since days of tsx-11, but I digress.
Location: Vancouver
Remote: Negotiable, experienced
Willing to relocate: Negotiable
Technologies: Rust, Python, Cython, JavaScript, Common Lisp, Erlang, C; AWS, GCP; Ubuntu, Debian Linux, FreeBSD, macOS
Résumé/CV: Linkedin.com/in/dpezely or Pezely.com/daniel
Email: first name at last name dot com
Currently specializing in Rust:
- Over 2.5 years as primary language, and began with 1.0-stable in mid-2015
- Rust mixed with Kotlin for native Android app, where Kotlin handles just UI via RecyclerView, ViewModel, etc. (otherwise, I'm relatively new to mobile dev; Rust lib originally deployed in web app, and the plan is to use the same Rust library with Swift for iOS)
Generalist from prior specializations in concurrency, exotic data storage, dev-ops, Natural Language Processing
Samples:
- GitHub.com/dpezely/anagram-phrases (using prime number factorization, in Rust)
- GitLab.com/dpezely/chat-server (mio as the only networking library, in Rust)
- GitHub.com/dpezely/Effective-serde-By-Writing-Less-Rust-Code
Location: Vancouver
Remote: Negotiable, experienced
Willing to relocate: Negotiable
Technologies: Rust, Python, Cython, Common Lisp, Erlang, C; AWS, GCP; Debian-based Linux, FreeBSD, macOS/MacOSX; old school pure JavaScript in browser to exercise server-side API for delivering end-to-end functionality; learning Kotlin+Rust for Android Native
Résumé/CV: Linkedin.com/in/dpezely or Pezely.com/daniel
Email: first name at last name dot com
Currently specializing in Rust:
- Over 2.5 years as primary language, and began with 1.0-stable in mid-2015
- Rust mixed with Kotlin for going full Android Native, where Kotlin handles just UI (otherwise, I'm new to mobile dev)
Generalist from prior specializations in concurrency, scaling, exotic data storage, dev-ops, and long ago as a Unix sys-admin.
e.g., at Splunk/BugSense: rewrote the BugSense back-end from Erlang/Lisp/C to pure Erlang for ironically 25x performance increase. Server cluster saw several billion inbound requests per day non-stop from all time zones. (See GitHub for slides from Erlang Factory and other presentations.)
Samples:
- GitHub.com/dpezely/anagram-phrases (using prime number factorization, in Rust)
- GitLab.com/dpezely/chat-server (mio as only networking library, in Rust)
- GitHub.com/dpezely/Effective-serde-By-Writing-Less-Rust-Code
There's a hedge fund encouraging companies for which they have significant holding, that if these companies don't improve their carbon footprint and related impact, management would be voted out. (overly simplified)
Archived version:
http://web.archive.org/web/20191216015241/https://www.tcifun...
Within a San Francisco company recently, suggesting that they create FSM diagrams was met with resistance that such things seemed frivolous.
Asking for Sequence Diagrams, they presented an architecture map.
This confusion occurred with most of the people I asked: e.g., team lead and manager, each with more than a decade of professional experience. This company is well over a decade old with significant recurring revenue, so obviously they must be doing everything right-- Right? Suggesting how to have assurances for correctness was eventually taken into consideration, so I commend them for that much.
Unfortunately, they are not unique in that way. While I only have a small sample size of a handful of Silicon Valley companies that I've experienced firsthand as employee or visitor, that was the pattern at all but one. (The one exception was BugSense, by the way: freshly imported from Greece.)
At least with a tool like sketch.systems, defining an explicit FSM as part of a prototyping tool may satisfy places that insist that "docs go out of date".
Suggestions for features:
1. in addition to the JavaScript for behaviour mock-up, consider also supporting WASM.
2. If the behaviour mock-up code could be called from an API, integration tests could also confirm a mismatch between design versus actual.
GitHub.com/dpezely
GitLab.com/dpezely