We’d set up a dummy HMI and have someone pressing buttons on it for the demo, and someone in the next room manually driving outputs and inputs to make it seem like it was working. Very common.
To me it sounds like lying...
Context matters a ton though. Are you presenting the demo as if the events are being automatically triggered (as in the OP) or are you presenting as this is your plan? Explicitly. If it is implicit, it's deceptive. If you explicitly do not say what parts are faked, it is lying. Of course in a magic show this is totally okay because you're going to the show with the explicit intention to be lied to, but I'm not convinced the same is true for business but I'm sure someone could make a compelling argument.
And yet, you’ll still have people here acting like it’s totally fine.
As you said, it’s one thing to demonstrate a prototype, a “this is how we intend for it to work.” It’s a whole other thing to present it as the real deal.
Like you say it can be useful as a way to uncover overall process or UX issues before all the internals are coded.
I'm quite open about what I'm doing though, as most of our clients are reasonable.
It’s called prototyping, in this case it would be a hi-fi prototype, and it lets you communicate ideas, test the implementation and try out alternatives before committing to your final product.
Lo-fi prototyping usually precedes it and is done on pen and paper, Figma, or similar very basic approaches.
Google (unsurprisingly) uses it and has instructional videos about it: https://youtu.be/lusOgox4xMI
Relying on blackbox components first mocked then later swapped (or kept for testing) with the real implementation is also a thing, especially when dealing with hardware. It's a bit hard to put moisture sensors on CI!
That said...
I would have recommended at least being open about it being a mockup, but even when doing so I've had customers telling me "so why can't you release this tomorrow since it's basically done!? why is there still two months worth of work, you're trying to rip us off!!!"
Looking at this a different way, they gave first-year students, likely with no established pre-requistites, an open-ended project with fixed hardware but no expectation to submit the final project for review. If they wanted to verify the students actually developed a working program, they could have easily asked for the Pi's to be returned along with the source code.
A project like this was likely intended to get the students to think about the "what" and not worry so much about the "how." Faking it entirely may have gone a bit further than intended, but would still meet the goal of getting the students to think about what they could do with this computer (if they knew how)
While university instructors can vastly underestimate student's creativity, they are, generally speaking, not stupid. At the very least, they know if you don't tell students to submit their work, you can often count on them doing as little as possible.
Wait, is your argument honestly "it's not cheating because they just trusted the students"?
There's a huge difference between demoing something as "this is what we did" vs "we didn't quite get there, but this is what we're envisioning."
Edit: You all are responding very weirdly. The cheating is because you're presenting "something" that is not that thing. Put a dog in a dress and call it a pretty woman and I'll call you a conman.
In US colleges at least (only because that’s where I have personal experience…not because I believe standards are any higher or lower here), this is cheating if they led their professor to believe that it was indeed the raspberry pi sending out an email rather than someone at the back of the class.
But what if the Pi was only ever meant as a story-telling device to get the students thinking about the kinds of things computer programs can do?
Sure, some of students would be able tell a story by building a functioning program, but dvsfish simply found another way to tell theirs.
>> It was our first comp sci class ever
>> asked to create "something"
It doesn't matter what that "something" was if you are claiming that you made "something" else. The lie is not necessarily the final result, it is the telling of the final result. The context of the whole thread is also about deceit because rtfa.
They did use the hardware provided, and did use software to accomplish a goal. If the teacher just wanted to test what problem solving skills the students walked in, I’d say that’s a fair result.
For anyone not getting why this is cheating, try this. Pretend you are the teacher. You saw students pull this stunt and say that it was a live demo. Would you feel like you were deceived if later you found out it was not in fact how they presented it? (I'm honestly unsure how you can answer this in the negative)
Or how about you watch an ad of someone taking to a box and the box responding, then you buy the box and it's a pile of rubber bands and paper clips. Would you want your money back?
Well if you're the TA and you're unwilling/too lazy to call out the conman, I call you an accomplice! Also, since when was the ideal scientific rigour ever build on interpersonal trust?
Garbage in, garbage out.
Here’s a whole list of projects intended for kids.
https://all3dp.com/2/best-raspberry-pi-projects-for-kids/
It includes building out a whole weather station which includes a humidity sensor as one of the many things it can do.
yes for whomever organized such a curse and didn't give such guidance.
And besides curse asked for project to do something. It did. It printed lines. We can call the email gimmick, the marketeering strategy, making a turd look good.
Don't blame students for failure of whomever designed the curse.
The problem with the email isn’t it’s a gimmick etc. it’s that it appears quite clear that the students created the impression that it was the Pi doing it.
Your excuse that it’s difficult for first year college students with no coding experience to do something useful with the Rapberry Pi is disproven by the fact that there exist many extremely useful projects that kids with no coding experience can do, so college students almost certainly should be able to do without needing to resort to gimmicks.
So I don’t understand your complaints about the course. It’s clearly not too hard which is what you’re implying. And if you’re suggesting that the wording for the project wasn’t clear enough then that’s a huge claim to make considering you don’t know what the wording was.
Also, college (at least in the U.S.) was never about playing funny word games with the professor. There’s a level of maturity, reasonableness, and respect that is expected of the students. None of which is indicated in the response here.
Given that the general teaching style of colleges isn't unique to the US, and based on my experience throughout my degree at a similar institution, I somehow doubt that statement.
> It’s clearly not too hard which is what you’re implying.
It sounded like the students received literally no guidance, in the way the course is described. These types of assignments usually result in those with previous programming experience showing off their skills, while the actual rookie students are left in the mud. I.e. an assignment that targets the top 20% of the class.
Regardless, to my knowledge I never cheated during my college degree, but I can't hold it against people that do. Criticism such as yours disregards the reality that students face, pressure to graduate with good marks and whatnot. Not cheating will put you at an disadvantage, because your competition is actively doing so and they are already skewing the marks that way. If the intention of the assignment was to identify honest work, it was certainly structured wrong (as a required submission would have eliminated the cheaters).
Literally all that matters is that they passed.
Are you trying to bully me or something? Not going to work with me. You've revealed your poor character with that comment.
The Wiimote connection was the star of the show by a long shot :P
My group (3 of us) bought a moisture sensor to plug into the pi, and had the idea to make a "flood detection system" that would be housed under a bridge, and would send an email to relevant people when the bridge home from work is about to flood.
So for our demonstration, we had a guy in the back of the class with gmail open ready to send an email saying some variation of "flood warning". Our script was literally just printing lines with wait statements in between. Running the script, it prints to the screen "awaiting moisture", and after 3 seconds it will print "moisture detected". In that 3 seconds I dip the sensor into the glass of water. Then the script would wait a few more seconds before printing "sending email to [email protected]". We then opened up our email, our mate at the back of the room hit send, and an email appeared saying flood warning, and we would get full marks.