Technologies: C, C++, Java, go, python, javascript, and many more. I've been building stuff professionally for 15+ years and I've never been picky about tech stacks.
About: Making software for 15+ years, for various companies across different projects. Most recently spent time as CTO of a fintech, wearing all the possible hats. Looking for the next exciting thing to build.
Reachable through email and/or linkedin. Willing to listen to proposals and to provide any information you might need.
It explains in a lot more detail than the mailing list post what TLEM is about and how works.
Choice quote from the abstract:
"Our emulator can handle bidi-
rectional traffic at speeds of over 18 Mpps (64 byte pack-
ets) and 30 Gbit/s (1500 byte packets) per direction even
with large emulation delays."
(OP/author here) I think you should have asked before changing the URL.
The original URL pointed to the correct repository and had up to date performance numbers. Now it only points to the paper which is has stale information on both. Any chance to restore the original ?
If we asked before changing every url, we'd do nothing else all day.
I've put it back to the one you want, though I'm skeptical it's a better choice. It seems so to you because you know the project inside-out, but the audience here does not. The best story is the one that explains what it is, optionally with a comment in the thread pointing to updated information.
My off-the-cuff assessment is that tiered pricing will probably give you the most bang. This usually works better if you do it based on actual data of what your users do, rather than random comments from HN, but my guess is that you'll probably be able to segment into Hobbyists vs Small Businesses vs Big Fish without too much problem.
Following up with a number out thin air, I would say that $9.99 is sounds like a good ballpark for the lowest tier. Businesses should be willing to pay a large multiple of that (Think 10x and up) for any solution that solves a real problem for them, as long as you make the segmentation clear and market accordingly.
OTOH, If you are really married to "unit" pricing you can kind of keep it by giving each tier a fixed number of monitors/reactions plus the option of purchasing extra monitors/reactions at a fixed unit price (different per plan), but you should really look at actual usage data to figure out whether it's worth it. In my experience, simple tiered pricing works better.
Also. Completely unrelated to pricing but it made me cringe when I saw it: If I hit the call to action on the landing page I get to a form with a lot of empty space around it and no indication of what follows.
You should take advantage of that empty space to make clear what will happen to me if I fill out the form and hit the button. For bonus points you can point out some more benefits, or a testimonial that takes down a common objection to signing up, or whatever, but a simple bit of text saying "The next step will be like this" should make a measurable difference in conversions.
My email is in my profile if you want me to spout some more random unsolicited advice at you.
As ussual, patio11's "charge more" advice applies. You should bill at a rate proportionate to the value provided, not the effort required from you to deliver it. Your client knows what value they expect to get out of the training, but they most likely have no idea of how hard you have to work to deliver it to them (and even if they are inclined to guess, they will underestimate it). Listen to Patrick, use a ROI argument and negotiate on scope.
With that out of the way, I'm going to throw some caveats at you. The idea is not to discourage you, just to make sure you realize the effort that will go into preparing for those 40 hour of training you will deliver and price yourself accordingly.
As a first timer on professional training, be aware that 20+ people to train is a large number. You won't be able to achieve much personal interaction with each student, and you might find a great deal of variance in their backgrounds and skill levels at the start of the course. Be prepared for outliers, at both ends of the spectrum, they can chew through time that would be better spent on topics for the bulk of the class.
You will also find that large firms can be notoriously bad at gauging the needs of their teams, you could deliver exactly what is asked of you by the management without meeting the dev team's needs. Take a moment at the start to gauge the team's expectations, explicitly ask them what they want to get out of the training and try to work some of that into the lessons.
You will have to take some time to learn about the team you will be training: Are they distributed? Do they all work together? Are they already working with the thing you will train them on? Are they building line of business software? Are they being rented out to third partys? All of this will influence what the team and what management expect to get out of you, and therefore what you whould deliver. Be ready to manage expectations from both ends.
Does it sound like a lot of work yet? This is just the start.
TL;DR be prepared for pathology on your first engagement. Charge more.
Oracle's JD Edwards EnterpriseOne is an integrated applications suite of comprehensive enterprise resource planning software that combines business value, standards-based technology, and deep industry experience into a business solution with a low total cost of ownership.
Essentially, an ERP and set of buzzword-bingo cards in the same box.
an integrated applications suite = bunch of software interfaces for...
of comprehensive enterprise resource planning software = your business purchasing and maintenance problems
that combines business value = giving you the most bang for your buck,
standards-based technology = not sure about this one... can be tweaked by your IT department OR helps you select products/services that meet regulatory standards so that you won't get sued for cutting corners
deep industry experience = nobody got fired for picking something everyone uses
into a business solution = we will unpack and assemble it for you, but you should really buy the Gold Support Package or budget a lot more for your IT department, because it isn't compatible with anything else
with a low total cost of ownership = we make most of our money on the Gold Support Package, but will let you fool yourself into thinking that you won't need it.
My favorite sight when I review iOS code for clients is seeing a method on the App delegate that 'preloads' a bunch of singletons in one go. It sets the tone for the rest of the trip.
In my experience, a large bunch of iOS developers tend to use singletons out of imitation. The "sharedWhatever" is the usual way for the framework to provide access to anything that is purposefuly single-instance[1]. Same thing with delegation, though that one is usually less cringe-worthy in practice.
[1] The "the accelerometer on your phone" kind of single-instance, which is a much more defensible use-case than what the typical iOS coder uses them for.
Yes, it can be used, but it needs some work up front. Like all compliance schemes it is not entirely devoid of effort. There used to be a whitepaper outlining the basics somewhere in the AWS site, IIRC.
There's also a number of companies providing HIPPA-compliant cloud services at various tiers and some of the offerings are backed by AWS. So it's possible and it's been done already.
Yes I appreciate that a service like AWS can't give you HIPPA of 21CFR Part11 compliance, only supply tools that can be used that way. What I'm looking for are examples (e.g. white papers) that describe how people have done it, preferably having been audited too.
Having written an analytics reporting library [1] I wholly agree with this. The library should not have preconceptions of what you want to report, it should just get out of the way and let you report it. I call it the "Report them all, The User will know His own" approach.
[1] The client complained that all available ones were NIH.
Remote: Yes
Willing to relocate: Yes
Technologies: C, C++, Java, go, python, javascript, and many more. I've been building stuff professionally for 15+ years and I've never been picky about tech stacks.
Resume/CV: https://www.linkedin.com/in/daniel-arbelo-arrocha/ Email: darbelo at darbelo dot com
About: Making software for 15+ years, for various companies across different projects. Most recently spent time as CTO of a fintech, wearing all the possible hats. Looking for the next exciting thing to build.
Reachable through email and/or linkedin. Willing to listen to proposals and to provide any information you might need.