dpezely

The combined professional network of founders and initial investors can minimize impact and effects of many factors discussed in other comments here.

"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.

Book containing the original short fiction from William Gibson:

- 2003 edition: https://bookshop.org/books/burning-chrome-9780060539825/9780...

- 1986 edition: https://www.amazon.com/Burning-Chrome-William-October-Paperb...

Have you considered using Common Crawl [1], and if so, what was your assessment when compared to having your own spyders?

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).

[1] https://CommonCrawl.org

[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/

There's a list of Common Lisp resources on Xach's blog [1] that includes communities, which remains relevant despite being an old post.

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.

[1] https://xach.livejournal.com/325276.html

[2] https://planet.lisp.org/

There are several topics intertwined with solutions you seek: There's parts of speech (PoS) tagging, reducing to Lemma form, identifying end of sentence, etc.

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...

Off-topic with respect to Kotlin but relevant to the Java platform:

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

[1] https://clojure.org/about/history

For others considering Rust + Kotlin for native Android development, there's also the Visly blog post[1] with basic steps. However, since then, Google officially released `androidx`. Unfortunately, Android Studio or the SDK lack `cargo fix` features of modifying your source code and instead just magically compiles with a compatibility layer. There's a PR on Visly's GitHub repo with these code fixes.

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.)

It's worth noting the "My experiences with NixOS" discussion from a few days ago: https://news.ycombinator.com/item?id=22877355

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.

Daniel Pezely — Authorized to work for any employer in US or Canada

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

Daniel Pezely — Authorized to work for any employer in US or Canada

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

Indirectly, you may be able to accomplish tracking success by following the smart money, so to speak.

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...

Hopefully more people identifying themselves as software engineers will use Finite State Machines to better ensure correctness of the system.

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.

Also consider viabale options for Plan B: on the job training worked well for us even before Edition 2018 landed.

We had a senior level Java developer learn Rust on the job and be very productive within a couple of weeks. I joined shortly after and was experience with Rust. This former Java dev and I shared knowledge equally: I learned the Diesel ORM and our PostgreSQL integration from him with a few short conversations, and I perhaps helped abbreviate his remaining Rust learning curve with maybe three 1-2 minute conversations.

Another person at that same company was primarily a React developer, and he picked up Rust in fairly short order as well, but I had less involvement there.

A third person was fresh out of an extended bootcamp-style co-op program, and knew Java and React & React-Native, but this her first position after graduating. Note that she came from a non-programming background prior: goods trading industry. Also English is her third or fourth language. I walked her through potentially tricky bits of syntax and semantics (such as descructuring-bind for Structs) in an afternoon. Edition 2018 had long-since landed by her arrival, so that helped.

Modifying existing Rust code and following the patterns worked well. She started small but progressed quickly. Within a few short months, she was adding back-end API endpoints (actix-web pre-1.0) for her front-end needs, and she was creating new .rs files with most PRs merged as-is.

From prior experiences, such as using Python from 1999 through 2005 and Common Lisp between 2005 through 2012, you have an advantage when recruiting for a language considered "exotic" by standards of the given day.

At two different startups circa 2007 and early 2008, we received many, many very high quality candidates with a one sentence description posted to the right place (e.g., planet.lisp.org) saying, "Use Common Lisp in Seattle."

I've had comparable experience with that approach for Rust in Vancouver, BC last year when looking for devs that were merely "familiar" with the language, even if no professional work experience with Rust but "Ideal Candidates" having "Rust, Go, C++, C, Python or Lisp family of languages". That was posted via this-week-in-rust.org.

That one was posted with relatively poor posted salary, yet we still saw high quality candidates for the senior level role. The intermediate level dev that was ultimately hired apparently worked very well for the company after I left.

Thanks to the author and contributors for putting in the time and effort to create this.

Especially the cross-comparison in the second half is very thorough and useful!

Perhaps this or something similar could be hosted on a public git repo so that it can be maintained by a wider set of contributors?

There was a similar survey[0] of Common Lisp systems from 2007-2010 from before services like Github/Gitlab became prevalent, so maybe we can have something like this Rust library survey NOT suffer the same fate. (Yes, Fare maintained it for a while--thanks, Fare!-- after Dan passed away too young, and then it became less detailed[1], but you get the idea...)

[0] https://web.archive.org/web/20180824234333/https://common-li...

[1] https://common-lisp.net/implementations

The overhead of C++ adoption actually prevented us from ever moving fully in this direction.

Today, unlike in 2013 when they started, there are other options.

For others considering code-sharing, another option not mentioned in their article is Rust for the core with Swift and Kotlin. Between bindgen, futures, serde_json and non-nullable pointers in Rust, those would satisfy their stated subcategories today.

Companion templates are explained here: (January 2019)

Medium.com/visly/rust-on-ios-39f799b3c1dd

Medium.com/visly/rust-on-android-19f34a2fb43

(No affiliation other than starting to proceed down this path myself.)

For Common Lisp heads, there's also MOCL, which seemed quite reasonable when I explored it years ago: wukix.com/mocl

Details may change every few years but overall, it boils down to two main approaches: 1) find a position through your professional network, as an estimated 80% of jobs come through such connections; 2) be discoverable for the other 20%.

Be active in both.

Present something at a local meeting/event. Often, it doesn't have to be fancy or overly polished. Some events on meetups.com have a few people present for 10 minutes each.

Which leads to #2, be discoverable: put those presentation materials on GitHub or GitLab.

Additionally, there are common interview questions (whiteboard and/or code challenge) such as URL shortener (e.g., TinyURL) or anagram solvers. These have come up a number of times in my interviews over the past few years, so I wrote the code and pinned these on my GitHub profile. (Same user id as here, if you're interested.)

I decided to go a step further and give each the full dev-ops treatment: Dockerfile, Makefile, etc.

But give them a solution, not a problem.

Avoid relying upon AWS/GCP/Azure proprietary offerings unless that's precisely what you're demonstrating, and make it work as-is: fetch all dependencies with version pinning (if possible-- else put versions in README), so then you know that it will build for them exactly as it did for you.

Some differences between then and now are also different idioms such as CSS naming conventions.

See GetBEM.com - for Block, Element, Modifier naming.

For instance, current conventions are to put a class name on far more HTML elements than years earlier, and avoid using hierarchical specifiers. (Yes, I know, at first it may seem to defeat the cascading within "CSS" without the hierarchy, but it's more nuanced than first glance.) It's especially useful when hiring front-end/UI developers to maintain the project after your initial build, as many will have learned BEM at various coding bootcamps.

Daniel Pezely - Authorized to work for any employer in US or Canada

Location: Vancouver, BC

Remote: Yes

Willing to relocate: Negotiable

Technologies: Rust, Python, Common Lisp, Erlang, C; GCP, AWS; Debian-based Linux, FreeBSD; old school pure JavaScript in browser to exercise server-side API for delivering end-to-end functionality

Résumé/CV: Linkedin.com/in/dpezely or Pezely.com/daniel

Email: first name at last name dot com

Currently specializing in Rust: 2+ years as primary language, began with 1.0-stable in mid-2015.

Generalist from prior specialization of 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.)

Recently added:

GitHub.com/dpezely/anagram-phrases (using prime number factorization in Rust)

GitLAB.com/dpezely/chat-server (mio in Rust)

GitHub.com/dpezely/Effective-serde-By-Writing-Less-Rust-Code

Related:

A utility for transforming JSON at scale written using the Rust programming language is bumblebee and available on crates.io.

The author of that package uses it internally for massive amounts of data on a regular basis, and he's a bit too modest to use a higher version number.

He explains this at roughly the 40 minute mark. [1]

"There's 7 more lines of `unsafe` that avoids keeping both maps. You still keep two maps, but you de-duplicate the data between those two maps."

https://www.youtube.com/watch?v=s19G6n0UjsM&t=40m1s

How does your workload and server spec compare to theirs?

Following links to the OSDI'18 paper [1] gives this overview:

"Setup. In all experiments, Noria and other storage backends run on an Amazon EC2 c5.4xlarge instance with 16 vCPUs; clients run on separate c5.4xlarge instances unless stated otherwise."

That paragraph goes on to explain the nature of the workload.

Their Figure 2 gives example SQL commands.

[1] https://jon.tsp.io/papers/osdi18-noria.pdf

While drivers may remember to "reach across your body" with opposite arm because they're in driving-mode, passengers probably won't-- from personal observation.

Specifically, this is from experience involving a passenger door opening into a curb-side bicycle lane. The door opened before the car came to a complete stop and quite a ways back from the intersection. The car was still compressing front springs from braking when passenger door opened. (Enough other posts here today described what happened next.)

Since then, I wear bold red striped shirts or jackets when riding and red helmet.

When they found "Where's Waldo" (or "Where's Wally" for those from UK), I know that they've seen me, and that's the whole point.

I've used this very successfully in my present home of Vancouver, BC. Previously, it also worked well when residing in SF and Seattle. There was a confirmed Waldo sighting near English Bay just yesterday, but now you can call me by my real name.

Discovering patterns from chaotic datasets, albeit via Graph Theory techniques (instead of ML) for populating a knowledge graph. e.g., find commonalities among documents, such as a single occurrence of a common phrase in each that connects otherwise obscure papers.

This technique is well suited for datasets with insufficient features for machine learning...

Initial tech focus was on finding commonalities within a set of documents, such as by crawling all links on first 10 pages of Google search via their CSE API. Next search optionally increases the pool.

Initial business focus was for marketers, who not only know their pain but are willing to pay to make that pain go away.

Nothing unique about the market... but with Lean Interviews and with 100% hit rate for interest among the 40 highly qualified leads, it seemed like a simple matter of assembling various bits that we had each previously built.

Lessons learned:

Even if a long-time friend commits to joining, has the financial means to contribute several months, owes you the personal favour to do so, etc., etc.-- Don't bank on that.

Like a perfect storm, I had multiple friends who previously committed to assisting, then each suddenly experienced extenuating circumstances preventing them from joining. One would have been our NLP lead-- ouch!

More mundane lessons learned captured in articles:

https://play.org/articles/new-entrepreneur-checklist

https://play.org/articles/introduction-to-natural-language-p... (i.e., unlearning misconceptions about "synonyms" to fully deployed with spaCy.io)

I've brought or used CL in a few companies.

2005: At a bank dealing with mortgage secondary markets, we snuck it into the Research group (where "research" isn't R&D but feeding information to the trading floor) for plowing through dirty data from multiple databases before our DBAs could make it available via Oracle. This hack helped keep the math & stats PhDs’ pipelines full.

Rationale for using CL: because values have type rather than variables (but may be asserted with CHECK-TYPE; see Google CL style guide), this essentially gave us late-binding of schema.

2006: at Zillow, we were building autonomous server farm control at a time when AWS still emerging. Unfortunately, two things happened at the same time. 1) There was a re-org in Ops leading to discontinuing contractors, so both of us had a 2 weeks to finish it and finish early. 2) SBCL had just reached 1.0 after years in 0.x land. One modification in the run up to SBCL v1.0 that I overlooked in the changelog was how bindings for special vars were handled across threads. It required a trivial fix, but we didn't track that down before time ran out-- oops!

Rationale for using CL: 2 guys still learning the language (one also working on Masters) got lots of traction quickly.

2007: at an education administration start-up, same colleague as from Zillow and I began working on a conceptual sibling to Amazon Dynamo, roughly when their original white paper came out. In 5 weeks, we had an MVP; Kevin wrote all the code, I helped with design and code reviews; it handled arbitrary data payloads and migration of data "ownership" by node. We were about to begin multi-node load & capacity measurements when the business joined a Microsoft incubator and removed all Unix-only folks.

Rationale for using CL: 2 guys, lots of traction quickly... plus, late binding of schema via MOP tricks.

I would like to believe that parts of this continue as Kevin’s vivace-graph despite being a very different animal.

2008: at a Seattle-based ad network (I still bear the shame...), the geek-macho angle was that this is one of the few types of businesses likely to see billions of requests per day. In 4 months, we were deployed at RackSpace and completed baseline load & capacity measurements.

There was an issue with garbage-collection after Hunchentoot would release a HTTP connection, because by the time FreeBSD would release the underlying TCP/IP structs, several minutes would elapse before gc could reclaim everything. Not ideal, but it was manageable!

Rationale for using CL: 1 guy, lots of traction, successful hand-off to new hire (the guy who later brought Clojure to Amazon’s retail side of the house).

Bonus: local Angels and VC (Madrona) came to us but then came the economic crash of 2008...

2009: recruited into Memetrics, a former startup that had been acquired by big consulting firm, and the core software was already written in CL from nearly a decade earlier. I was only in the core group briefly, but subsequent work using CL was my default choice and already approved. (Then again, I didn’t ask permission or beg forgiveness.) There were more dirty data cleaning tools and a Recommender system from which China’s answer to Amazon became a client. Mind you, they didn’t use this code, as they had their own, but it demonstrated that our group understood the principles. I still count this as a win.

Rationale for selecting CL: was decided by folks in Sydney before I arrived. Their head-hunter found me after their acquisition.

2013: Splunk acquired BugSense. BugSense used "Erlang, Lisp and C" (Scheme R4) for handling billions of inbound requests per day non-stop from all time zones into our cluster. While not CL, having previously gone sufficiently deep into CL allowed me getting from zero to presenting at Erlang Factory conference in exactly one year while reaching more than 25x performance increase with the pure-Erlang rewrite.

Rationale for selecting Lisp by their founder: made for malleable query language.

2015: wife wanted to move back to Canada after several years in Silicon Valley. Resurrected a pet project circa 2007, snagz.net, and I attempted founding a company. Back-end is CL for Natural Language Processing work-flow. Core NLP things now use spaCy.io, because their NLP-fu is far better than my self-taught version. Some intermediate working data sets were pushed into a slightly modified Anarki fork of HN, partly to see what the Arc language was about, and partly because that tool fit the (internal) need.

Rationale for selecting CL: Lisp is a beautiful language within which to work.

Others in and around Vancouver using CL: Routific mentions Rust and Common Lisp in their job postings; D-Wave previously mentioned Lisp in job postings but unable to see it today; there was at least one other, but I can’t recall.

In my early experience with Common Lisp, I would have said MACROS were key.

Then, pre-populating memory followed by #’sb-ext:save-lisp-and-die was a handy trick for improving cold-start times. (Alternative to using POSIX mmap().)

Now, it’s simply the joy of writing code in the language.

First milestone: parens disappear, because using the right editor config means never typing a single paren, and editing involves manipulating whole expressions with fluid motion.

Second: thinking how a function should be or might be named, points to something either in the HyperSpec or be the name of a package, thus easy internet search. Today, there’s Quicklisp.org and Quickdocs.org, making this even easier.

That said, I’m currently learning Rust and React-Native for a tiny mobile app, as each language can teach you something new.

But something in the Lisp family will be with me for the rest of my days. I might go with Racket next just to expand my knowledge there.

So I recommend: use Common Lisp for a real project-- just because you can!

FYI: there's currently a DNS problem for "sbcl.org", so instead, please use what it ordinarily points to:

https://sbcl.sourceforge.net/

If you're starting to learn, please contribute to http://Lisp-Lang.org at the very least by highlighting parts that may need improvement for a new learner by opening an issue at https://github.com/LispLang/lisplang.github.io

But to answer your question directly, when I was re-learning CL circa 2005 long after university, I populated these pages as I went along:

https://play.org/links/lisp-intro

https://play.org/links/lisp

(I've meant to fold content from those into Lisp-Lang.org but never found/made the time. I did, however, prune obsolete bits earlier this year.)

Best of luck to you!

If you or anyone seeking to learn is in Vancouver, Canada, feel free to reach out and meet for coffee/tea/beer/cider.

Python 3.7 was just released, and 2.7 is to reach end-of-life/sunset in 2020 after they already gave it a five year extension. As the linked PEP 404 makes clear, there will be no 2.8.

Several recent conversations indicated that none from that small sample have actual plans to migrate. Google App Engine still offers 2.7, for instance, further feeding the addiction.

I wonder whether the inevitable migration could become an opportunity to get other languages in the door at companies like that-- e.g., those using App Engine on 2.7. Yes, most will take the path of least resistance and go to 3.x with business as usual.

However, will some turn this into an opportunity at their companies to overhaul now-legacy code? Change major frameworks? Perhaps consider newer languages like Rust or Elixir?

4. Once upon a time there was ___. Every day, ___. One day ___. Because of that, ___. Because of that, ___. Until finally ___.

I believe this line comes from Brian McDonald and am witness to his use of it in a writing class he led at Seattle's 911 Media Arts circa 2000. (The number in their name was in reference to the original address on E Pine St.)

https://en.wikipedia.org/wiki/Brian_McDonald_(screenwriter)

He is both an accomplished writer and excellent instructor for writers. I found his guidance to work well in tandem with McKee's STORY.

His early works are of spectacular quality (e.g., White Face), and this reminds me to get caught-up on his more recent material.

SPI did not directly have game servers, but yes, at least one of our members ran one. I don't recall if it was a MUD or something else.

Speakeasy also had other co-location hosts in the rack. If I recall, one was for a design firm somehow connected to one of the owners. Maybe there was a game server there, too.

For a bit more historical context on the Seattle Peoples' Internet, I slapped this together: https://play.org/articles/seattle-peoples-internet