Bleach? I would hope not. This is spraying your anus, which you should avoid using soaps (or holy shit, bleach?) and only use water or specific soaps. Same with your penis, which I hope you're not washing with regular soap (or bleach)
I have a startup, we have a nice new product -- and obviously, there are some product specifics ,so we have our own support team, that we train to learn the product, and be able to answer customer questions, and so on.
If I hire Assembled to help with support, what can they provide?
Obviously, they will have zero knowledge of the product. What can Assembled help with here?
Is this about fending the first-line questions, like "please reboot your computer"?
BTW there is like thousands of companies that do that. Not clear what is special here.
> If I hire Assembled to help with support, what can they provide?
> Obviously, they will have zero knowledge of the product. What can Assembled help with here?
These are very good questions and they raise a very valid point: Assembled will not have deep knowledge of your product (at least not as deep of a knowledge as your own support agents). However, we do have deep knowledge about how support teams are run in general. We've talked to hundreds of support teams, large and small, and are knee deep in the customer service industry.
Our product doesn't answer front line support questions, but rather helps you manage agent schedules and determine the best times to staff your agents. To do this, we forecast support volume, and correspondingly, how many agents are required to handle that volume. This is important because a large part of great customer support is how quickly you're able to respond.
This is a much different way to improve support than by just answering questions. We try to make your team more efficient without the need to hire more people. The cool thing here is that you can still layer on deflection systems (to reduce ticket volume) and enhance agent performance (via QA systems) in addition to what we do.
Datomic is immutable in the sense that what you had for lunch today doesn't change what you had for lunch yesterday, where "lunch" is any arbitrary fact stored in the database.
I.e., you can ask to look at the entire database as it was yesterday, and run arbitrary queries against it.
You can also do speculative updates to it, in the sense of "show me the entire database as it would be if I were to have pizza for lunch".
It models this as a strictly linear succession of assertions and retractions of facts. Yesterday, `A` was true, today `A` is no longer true. While this new fact is recorded, it doesn't change the fact that yesterday, `A` was true.
What we see in reality is that append-only database is unusable without making additional "projections" or whatever you call them, databases that are ready to be queried/updated, with maybe specific denormalizations, indexes and so on.
And oh, btw, those later databases are not "imutable".
Dstomic is an immutable log (kind of like git). the only operation is append. there is a head pointer stored pointing to “latest”, this is the point of mutation you’re looking for, and it’s the only point.
As far as I know minifiers don't do this since it changes semantics. Take this for example:
// 1
doSomething();
console.log(Math.sin(2));
// 2
var s = Math.sin;
doSomething();
console.log(s(2));
Now, consider this definition for `doSomething()`:
function doSomething() {
Math.sin = x => x
}
Now, the first prints 2 and the second snippet prints 0.9092.
Keeping track of globals to get around this is complicated. Even if you do, you can't always be sure the behaviour of the code isn't changing since `doSomething` could be defined in a module your minifier doesn't know about.
>> NULL doesn't really mean unknown; it means that instead of having a pointer to a result-set, you have no such pointer.
NULL in SQL has nothing to do with pointers.
It means that the value is missing or otherwise unknown.
Consider the column that is tracing the reading of a meter of some kind.
And let's say that we could not get a reading -- due to some fault.
So we did a reading, and we want to record that. What "value" should we record? 0 is no good - may make you think that we recorded a reading of 0 - which is not true.
NULL is the solution - it specifically tells you that the reading is missing or inapplicable.
Obviously, this complicates things, but incidentally translates well to other languages that have a (completely unrelated) concept of a null pointer.
Yes, relational algebra isn't a pointer machine. I was trying to give a mental image of what is going on—the resolution or lack thereof of tuples in a tuple-space.
Let me try another analogy, that might suit you better: if you think of each row-tuple in a relation in SQL as an asserted "fact" in a logic knowledge-base, e.g.
INSERT INTO parents VALUES ('x', 'y')
equates to the logical assertion:
parents('x', 'y').
...then a NULL result in SQL is the equivalent of asking your theorem-prover to look at this knowledge-base and deduce the truth-state of other fact you never told it anything about, e.g.:
?- parents('a', 'b').
...and getting back "unsat" — meaning that the theorem-prover couldn't prove your assertion true or false.
A theorem prover has the option to answer any question as Satisfied (Result) | Unsatisfied. This is what I meant by saying "a pointer to a result set, or a lack thereof." NULL is when you don't have such a pointer—which is why it's called NULL, by analogy to the DBMS's C implementation where the rowset pointer itself is likely set to be the pointer sentinel value ("NULL" or 0), rather than set to point to an empty rowset. The name NULL probably ended up in SQL after "bubbling up" from the implementations of the DBMS engines in this way.
The Weird Thing About SQL is that the grammar is phrased in terms of individual rows, whereas the query-planning occurs in terms of relations. So, when doing joins, you need a way to talk about what maps to "a join of a populated relation to an unpopulated relation", which in terms of individual rows, necessarily translates to "a real row-tuple value on one side of the join, along with some scalar sentinel row-tuple value [NULL] on the other side, standing in for 'a member of' the empty result-set."
That's the core semantics of NULL in SQL—to give you a 'scalar handle onto' the fact that there's no row on the other side of a join. That's where NULLs "come from", if you don't introduce them yourself (i.e. if you never make any of the columns in your tables nullable.) And so those semantics must be what you look at when figuring out what NULL "means." In joins, NULL doesn't quite mean "missing" or "unknown", but rather a combination of the two; it means "unsatisfied", just like in the theorem prover; it means that the query-planner has not yet been told enough to resolve your query fully.
(Yes, you can model an ingestion semantics where any row-tuple value that's not "in" a table, means that whatever predicate is represented by the presence of a value in the table should be considered to resolve false in the relation—but that's not really how SQL query-planning sees the world. It thinks of rows it doesn't have as "nobody bothered to tell me this yet"—unsatisfied—rather than "explicitly missing"—false. If you want false-ness semantics in SQL, it'd probably be better to define a view that generates rows with zero-values/false-values where the underlying table doesn't have values, and join to that instead.)
...I think you are misunderstanding the whole reason for the IS NOT DISTINCT FROM operator, which is exactly that.
"SELECT NULL = NULL" will return NULL, use that if you want the standard way. There are many cases where you want it to return true though, and the boilerplate for that sucks, so IS NOT DISTINCT FROM has a very useful place in the dialect.
I bought mine off Amazon for like $40 and it does that.
BTW I do clean mine now and then, and there is like, almost nothing to clean. Compared to e.g. my humidifier, that needs almost-daily cleaning.