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."
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.
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.
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.
Here's a nickel kid, go buy an operating system with decent man pages.
Now the mandatory joke is out of the way, it looks cool :) The examples tend to the trivial for now, but I assume that the voting system will probably take care of than once the more advanced submissions start to come in.
The easiest place to start testing is likely to be in the code you are touching now. It is fresh in your head, you know what it does. Write a test for that, it shouldn't take you too long.
If you are doing a targeted bugfix (i.e. not with a shotgun) you already know the test you have to write: a test for the bug. Try to first write the test and then make it pass (also know as fixing the bug), so you know that the test will spot a regression on future runs.
If you are working on a new feature, try to isolate the core logic of the feature and test that. If you can, test it in isolation from the rest of the system and integrate it after you have achieved some semblance of correctness.
If your code base has parts that you only touch rarely and you know (or hope) are reasonably solid, leave them for later. The highest risk for breakage tends to be near the spots with the most code churn, so put your tests there.
Also remember that tests are code and they must be maintained as you would maintain the rest of your code. Writing tests for implementation details that have no real impact on program correctness won't yield you much value when weighted against the cost of their maintenance.
If you are after the most "value per test" think about it this way: The most valuable test you can write today is the one that will catch breakage tomorrow. So, think of the code most likely to break (or the one that will hurt you the most when it breaks) and test that. The first time that test unexpectedly goes red, it will have paid for itself.
The "mbuf chain stupidity" refers to the way memory buffers are handled in the kernel. His implementation uses 'pbufs' to store a single packet contiguously in kernel memory. This is in contrast to BSD[1], where a packet could span multiple 'mbufs' which were 'chained' into a linked list.
You can "man 9 mbuf" on your nearest BSD derivative to glean a bit more information about what he is opposing. Today's mbufs are not quite the same as they were back then, but the parts that he hated are still there :)
[1] "my kernel looks nothing at all like any version of BSD"
Worth reading even if you aren't a perl guy. Every language has this type of 'cultural markers' that set your expectations for a codebase by skimming a few files or just the project structure.
On that first dive into someone else's code[1], this markers are invaluable, they are the first cue into the author's mindset and background. They are a signal for future maintainers or collaborators. It's like stepping off the plane and hearing people around you speak with your own regional accent. Even if you've never been here before, now you know some of your knowledge still applies.
[1] Rule of thumb, if you haven't touched your own code for a long time, think of it as being written by someone else. You are not the same person you were when you wrote it.
I used to be an embedded guy (assembly, C, C++ and actual hardware) then I transitioned to mobile and web work about six years ago. The last two years I have been doing mostly native mobile with iOS and Android.
Bottom line: If you want to build anything that has to run on a phone or tablet, I can help you out.
You can reach me at [email protected] for any questions.
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.