Right, but let's assume we have really simple crud application in mainstream language, could be ts or python. What are current best approaches to have this semi-formally verified, tools, methods, etc?
Hi there! Like I said in the post, we're actively developing support for JS/TS next, and are building toward a language-extensible project. We started with an open-source Python tool. :)
That would be 2.54 times 1/100th of the distance light travels in a vacuum during 1/299,792,458 of the time it takes for 9,192,631,770 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of a cesium-133 atom, if you prefer.
While there is a 1 inch measure in common use that is as you described, the subject here is EMT. There is no dimension in EMT that is 1 inch by the system you describe. The diameter is close to 1 inch, but it is noticeably different to the naked eye, and for all useful purposes different enough that anything actually 1 inch in diameter is not compatible.
You see a lot of this in the bicycle industry. There are a lot of older standards in use like 9/16” pedal threads, 1 1/8” steerer tubes or 1” (25.4mm) handlebars but any new standard is metric - so bottom brackets, wheels, newer seat post diameters are all metric. It can make for some very strange looking spec sheets.
So yeah, a weird measurement unit. Technically the symbol to be used is a prime symbol (https://en.m.wikipedia.org/wiki/Prime_(symbol)), but what’s used in practice is anything that looks close enough.
I would like to - but unable to find any libraries / engines that would function in a some sort of 'mocked' environment. for example - i need to cover all execution paths for only single function with high cyclomatic complexity, given all other stuff is mocked. Maybe it would be called unit test mix with se. also for dynamic languages such as php/python/ruby.
It's a good question. We would like to make it usable as a platform for dynamic analysis. The idea being that you can control all these external factors (like thread scheduling), find a crashing run, and then ask introspective questions of what the code is doing in a crashing run.
In practice, one challenge we have is bridging between the runtime view of the software (as a debugger would see) -- raw machine instructions and system calls, and the static view that you would get from analyzing the source code.
Sanitizers, for example (ASAN, TSAN, etc), are typically implemented in the compiler as program instrumenations. If we integrated binary instrumentation tools like Intel Pin or DynamoRio, we could perform additional dynamic analysis, but still at the machine code rather than source code level, which is a big gap from how symbolic execution normally happens, at the source code / AST level.
Yeah, I would be interested in this as well. I'm not really up for paying $39 for a half finished landing page of info built using reworded Tailwind UI components.
I agree. The landing page isn't the nicest one. I'm not a designer, though, and I'd rather spend that time improving the product. Is there anything you'd like to see in the extension that'd convince you to pay for it? Happy to improve!
I totally understand the use of Tailwind UI for an easy way to achieve professional looking components; I use it every single day at my job.
At the same time, you're targeting this product towards customers who are already developer-oriented — a crowd that is familiar with, or can easily recognize, the same technologies you've used to build Monito. Tweaking the designs to have a more custom flair so it doesn't seem so copy and paste, avoiding the same icons for multiple figures, and especially lowering your price are all things that would probably help with early and continued adoption IMO.
As for things you could include to justify the existing price, I really don't know. There's a heavy difference between paying for a desktop-application license vs a browser extension.
we developers are a stingy lot. I wouldn't base any pricing decision on what technical/developers say. The ultimate customer for this is a support person who is going to give feedback to a developer. To them and/or a QA team, you could be saving them a ton of time with this product. Consider that birdeatsbug starts at free for personal use and then $39/month. You might actually be leaving money on the table if you go $39 one time. Just something to consider.
At this point the price is 39$ because the product itself isn't polished yet. Now I can see it's actually needed and I'm going to add some nice features. Then it'll go up to ~59$ as it won't be an 'early access' anymore.
> anything you'd like to see in the extension that'd convince you to pay for it?
Different pricing scheme, at least in the beginning. While $39 (or even $59) is acceptable as one time payment, I am not sure if I am willing to pay this for a product that's been on the market for only 3 weeks and whose future is unknown. Charging something like $1-$2 per month will earn you more in the long term and will provide a safer option for the customers (they won't loose too much if you disappear in a couple of months).
BTW, at the organization where I work, we can only make payments to established entities, i.e. someone who has address, account number and can issue an invoice. I guess Gumroad, as a middle party, can provide all of these, still it would add to your credibility if you had an "About" page with the necessary data. Oh and a Privacy Policy would be nice too - some organizations won't allow installing any extensions that are not reviewed by a security team and such reviews often involve checking privacy policies.
Good point about credibility. I'm going to improve the landing page with a proper about page. I'll also add a privacy policy. From the start, I wanted it to work 100% locally, so I don't have to worry about sensitive data. Now it only uses some ids needed for trials and licenses.
About pricing, I don't think that model would be better. As a solo developer, it's better to charge more and provide better support to fewer customers. I'm not saying no, but it seems to be working well for now. Thank you for the suggestions!
