|
I think you are spot on with this.
-- rants are the vehicle of the lazy and uninspired - JSOP 2/2018
|
|
|
|
|
That is really a very personal Statement: In case a member thinks he is to good/high rep to ask a question un-anonymously (how this would really called this un-anonymously?), he does not deserve an answer!
As a voice of low rep members I still would like, that questions can't be downvoted.
Only my two Cents to the discussion.
Bruno
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
It's not about being too good to ask a question. It's about worrying what people would think if they asked a dumb question.
It's a small percentage of users for sure but it got us thinking "why do we need to identify the person asking the question at all?" Hence the experiment.
cheers
Chris Maunder
|
|
|
|
|
"if they asked a dumb question", I think that is exactly the same like "to be too good, to fail". But nevertheless a good Experiment, looking Forward for the results (if the results would ever be published).
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
Personally I think this is a good idea. Benefits I see:
- Question from a user with lower reputation is not so easily down-voted. The vote is probably is more related to the question itself. Probably also applies to high rep questions.
- Personally I'm not worried if the question is dumb or not, but I think that some people are afraid of answering a question from a high-rep user. Anonymous questions should help that.
Few problems
- If the question is inappropriate, how do I report the user?
- If the OP posts a comment to the question, I can see who he/she is. Shouldn't also the OP's comments be anonymous
|
|
|
|
|
Imagine, a question is not clear enough and some one is posting a comment to bring lights to the question. High-rep member reply the question and His comment is visible. In this case everyone knows who's an author of the question.
Personally, i don't afraid to ask a question, because nobody's perfect and does not have enough experience in everything he starts to work with.
Quote: Who asks not stray
[EDIT]
On the other hand, how can i report a user who's posting spamm on QA forum?
modified 21-Feb-18 2:49am.
|
|
|
|
|
Only FYI: It seems not to be completely anonymous. Having a look to the source of the question one will see the author information of the question.
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
Bruno, i can't find a way to take " a look to the source of the question"
Where can i find such of functionality?
|
|
|
|
|
Hello Maciej
With source I mean the html source. The following I did with IE 11:
a.) Open a question
b.) Right Click in an empty space so that IE context menu will be displayed and choose "View Source"
This lets you see than something like this:
"author" : [{
"@type" : "Person",
"name" : "Member 1##9",
"url" : "https://www.codeproject.com/script/Membership/View.aspx?mid=1##9"
}],
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
OK. Got it.
Thank you, Bruno. Nice to "see" you.
|
|
|
|
|
It's not meant to be truly anonymous. You can go to a member's profile and see their questions, too.
cheers
Chris Maunder
|
|
|
|
|
When I'm logged out and look at a question, the author is indeed invisible. But when logged in, it shows up. As you didn't mention any exceptions to the rule of invisible names, I'm wondering: is that a bug, or by design?
The quick brown ProgramFOX jumps right over the Lazy<Dog> .
|
|
|
|
|
An exception was made for Moderators.
cheers
Chris Maunder
|
|
|
|
|
Not really a question, but I thought you'd like to know I have added your CSystemTray class from 1999 into a new project, where it will probably reside for the next 20 years.
m )
|
|
|
|
|
Chris, Did I piss someone off? My messages all all being flagged as potential spam, although they are not.
Also, my reputation points seem to have disappeared, as well as my icon for subeditor.
What Did I do? If I abused the site or something, I assure you it wasn't intentional!
Greetings,
Walt
|
|
|
|
|
Sorry I just saw this message.
No, you certainly haven't pissed us off. Have you changed email or deleted articles or posts? Have you made any changes to your account?
I'll dig in once I know which direction to start digging and get this sorted.
cheers
Chris Maunder
|
|
|
|
|
Have you ever seen an article appear on the homepage and not had time to read it? We've added a small tool that will allow you to mark articles to be read later.
Once you've clicked the read later button your reading list will appear at the top of the page next to your name.
We hope this makes life a little easier.
cheers
Chris Maunder
|
|
|
|
|
It’s been about 9 months of work, on and off, but Matthew’s baby is finally live and kicking.
The Follow system was built to solve the problem of letting our readers follow the articles and posts they are most interested in. We have some pre-set filters on the homepage but they were never enough, never fine grained enough, and never up to date.
You can now just click on any tag you see, anywhere, and that’s added to their list of tags you follow.
You can also follow a person and see all their posts, or follow an article and have the comments on the article appear on your timeline on the homepage, or follow a contest and see who’s entering and what they have posted.
You get to build up the content filter you are most interested in instead of relying on our biased selections. Not interested in Microsoft stuff? Don’t follow it. Only want to see stuff on artificial intelligence? Tag it and we’ll keep the content focused on that. Want to see what your friends are posting both in the forums and as articles? Follow them!
As always, feedback and bug reports appreciated.
cheers
Chris Maunder
|
|
|
|
|
We've had various requests over the years to support video in articles which we've done using a variety of methods. We had our own <silverlight> tag for that brief period Microsoft was offering free silverlight hosting, then the <movie> tag to cover flash movies.
While convenient for some, they never worked for blogs or for those used to doing it the real, proper way. And with the web being the web the "proper" way is simply to throw the video inside an iFrame.
So to add a video to your articles simply do the following
<iframe style="height:250px;width:100%" src="//youtube.com/embed/ABCD_EFG"></iframe>
The article editor will show only a placeholder while viewing in WYSIWYG mode.
The current list of supported video hosting sites are:
- YouTube (youtube.com, youtu.be)
- Vimeo
- Channel 9 (channel9.msdn.com, sec.ch9.ms/ch9)
- Vine (vine.co/v)
Plus
- Slideshare (slideshare.net)
And as a bonus extra.
Simply replace the src URL with the URL of the embedded resource, set the width/height, and we'll take it from there.
cheers
Chris Maunder
|
|
|
|
|
|
Just want to clear it...
Videos linked from articles still has to be judged by the same guidelines as the article itself? I'm asking especially about ownership...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
Team 1: connected cars.
Team one discussed deploying an Apache Kafka cluster on AWS to handle data processing. A light blog that didn't really add much to the understanding of what's actually going on. They've since published a final blog[^] that summarises what they accomplished. What it comes to is an application that shows a map with other drivers in the vicinity. The key feature is a "driver score" that alerts the user to the crazy factor of other drivers. Lots of dramatic music.
Frankly: I don't get it. The entire project could have - and frankly should have - been a simple smartphone application. Smartphones have GPS, accelerometers, data connections and standards libraries, APIs and massive programming support. The inclusion of an arduino unit and Dell Wyse was not adequately explained.
What I would have liked to see: a smartphone app to handle the communication and UI. The arduino connected directly to the OBD port of the car to get driving dynamics, which would then communication with the phone via bluetooth. At least a sketch of what it would take to have the application ultimately apply the brakes in case of an impending accident. What we saw was basically Waze without driving directions.
Team 2: DIY Smarthomes for Aging-in-Place
We're at the point where the teams are mow pulling it all together and Team 2 have given us a rundown of how their system would work. This is split between nicely technical disucssions on using Clojure on the Edison (thank you guys!) and general comments about coordinating wearable and sensor data through a local gateway. To me this seems like they are simply creating another HomeKit or Brillo. The addition of Edison based bridges to route bluetooth sensor data to the main gateway is an excellent idea. However, I'm still looking for the meat. Where's the backend services and algorithms that will take this data and, using machine learning, translate this into real-time Alerts of Impending Doom?
Ultimately Team 2 did not achieve their goals. What they did achieve is a great contribution to the developer community in their form of their work on Iotivity. However, this again underlines the issues with IoT: there are no standards. We're still fighting the tools.
Team 3: Cognitive Healthcare System for Rural Areas
Team 3 has also wrapped up their project and demonstrated their remote patient diagnostic application. It's basic - 4 lead ECG instead of 12 lead, a slightly questionable body temperature probe placement (probably to keep it kid-friendly) and nothing adventurous such as blood work included. It is a prototype, after all. Someone may need to see a doctor, though, because blood pressure of 102/85 is a little low.
The sensors are all controlled and their data collected by the main application. Communication is via WiFi, and data is then processed manually (lots of Python scripts) to detect anomalies. Two main thinks are apparent
The data acquisition is way too coarse. A cardiologist could never read an ECG of that form. ECGs are subtle and require a hell of a lot of training to read. Machine learning can certainly do the job, but only if the data is very, very good. They need to use some decent screen casting software. It was very hard to see what was happening on the screen in the demos.Overall the ssytem seems reaonably complete. The risk of mis-diagnosis is extremely high with their current setup but it's about the concept, not the actual data and hardware at this point. Again, I probably would have considered a smartphone app more appropriate given that power and WiFi in remote communities may be harder to come by than a simple cell tower. WiFi, bluetooth and a ton of processing power is in your hand.
Team 4 - Proximity carts
Team 4 have gone all out in the video[^] department with a fully animated video explaining their system. Unfortunately their video showed a slightly cumbersome UI turning on and turning off LEDs. I have no idea how this relates to. Frankly I'm lost
Team 5 - remote agriculture health sensing
Team 5 have been granted an extension due to shopping dalays. Before that they had a couple of posts about using Matlab for porcessing and the BeetleBot (sans laser beams, unfortunately). At this point there's no final solution that's been demoed. Hopefully by this time next week.
Security wasn't addressed
These challenges are meant to stretch the imagination and coding skills while showcasing the technology available. The Intel IoT kits are maturing rapidly and the availability of APIs, SDKs and toolkits is astounding. There's still lots and lots of work to do, though, and frankly fewer, more comprehensive options would help the community rather than more. I'm sad to see not a single .NET entry.
What was also not mentioned, apart from a brief note by Team 3, was security.Is data from sensors being encrypted or passed through secure channels? Are data files with personal data (health monitoring data, car sensor dara, home sensor data) being stored in plain text or encrypted? What scope is their for the data between sensors and the processing system to be hijacked? Could the accident prevention system be hijacked from within the car easily? What about another driver hijacking the signals from surrounding cars? Given that the remote health app was on a laptop, could personal health data be accessed by other apps on that laptop? Were remote webservices protected with authentication? Was all communication handled over SSL?
I saw a lot of time spent fighting tools. I saw essentially zero time spent protecting systems (and people) from harm.
In my mind the IoT challenge isn't the software or hardware. It's the data. Specifically, it's protecting the data.
cheers
Chris Maunder
|
|
|
|
|
The Ultimate Code Challenge continues.
Team 1 (inter-car communication) have given us an architecture diagram. It doesn't say a lot - except they are using AWS for hosting with Spark and ElasticSearch. There's "Data Processing" but on what we're not told.
My experience with AWS is mixed, but given this is a prototype then it's a sensible decision. As long as they keep tabs on costs. At this point they have a basic server running and can pub/sub to those servers.
Team 2 (Aging in Place) have a Clojure nRepl server running on their IoT devices. This is way cool. repl = read-eval-print loop. You type in a command, the server reads, evaluates and prints out a response leaving you with a blinking cursor waiting for the next command. We've all used one. The "n" means networked, so you have the server on one machine and you use a client to send the commands from a different machine. What this means is they can explore the device APIs using a simple command line without needing to go through a code-compile-deploy-execute cycle that would be needed if using, say, C.
Team 2 then has an excellent discussion on designing UIs for the elderly, and how best to (semi) automate systems. The only issue I have is that their project was meant to be more about looking at behavioural patterns of those in their twilight years to look for correlations between behaviour and undesirable incidents. The goal is to predict problems based on behaviour, not to necessarily reduce the set of behaviours in order to reduce the risk set. That's cheating.
Team 3 (Healthcare for Rural Areas) have managed to connect sensors to their gateway via Bluetooth. In this case a heartrate monitor. Someone's been putting the work in if that screengrab of a 43bpm heartrate is accurate! They then present a great summary of the heart's electrical system and ECGs. Excellent stuff, especially for those who have a fear of ST-elevation in their future (coughs nervously) but it's a bit of rabit hole. ECGs are very powerful. As is a simple matter of asking the patient how they feel or where it hurts.
Regardless, the team is embarking on a a project to use a biologically inspired machine intelligence technique to learn and read ECGs. Another rabbit hole discussion (addictive though) on the brain. I'd defeinitely recommend On Intelligence for more in this vein.
I'm not sure where this is going. Health is way more than an ECG.
Team 4 (Smartcart) seem stuck trying to design proximity detection using RSSI levels of each unique identifier of items on a shelf.
They then upgraded the firmware of their Arduino using flawed and missing documentation, arcane button timings and presumably lots of swearing. Lots of things broke.
This just doesn't make it fun for anyone. Systems need to be more robust than this. My heart goes out to you, guys.
Team 5 (FamrConnect) discusses the sensors they'll be using. Temp, light, sound. Also LEDs that could potentally be used to attract (and destroy) bugs. Friggin' laser beams? A sensor-laden remote controlled bug could be used send around a crp to gather data. I still think a drone would be better, but a bug would be better than nothing. A bug with friggin' laser beams even better.
cheers
Chris Maunder
|
|
|
|
|
Hi Chris Maunder, This is Bharathiraja Nallathambi from team Agro Hackers, Thank you for your suggestions for using bug with laser beam or drone, which will be the ideal option. We agree on that. We are trying to make use of the provided electronic components as much as possible, while maintaining the cost factor as low as possible. We will make sure that, we will take your suggestions and provide provisions in the framework for drone and bug with laser beam.
Thanks and Regards,
Bharathiraja Nallathambi,
Agro Hackers
|
|
|
|
|
We're in the thick of it[^] now.
Team 1 have gone an interesting direction and are looking at including an alcohol sensor in their solution. To me this is a good idea in theory, but won't work in practice.
- it's a little Big Brother. I don't want to send my breathe alcohol (and it's breath, not blood) settings to an unknown company.
- It's inaccurate unless it's setup properly (ie user has to blow for a proscribed period into a tube). Otherwise it could pick up alcohol from passengers
- it misses the point. The point being that distracted driving now kills more than drunk driving, and fatigue is right up there too. Instead of a seemingly easy solution that's doomed to fail, why not get smart and add some driver heuristics that will detect not only drunk, but distracted, fatigued, and drivers under the influence of drugs. Steering variability, braking patterns, speed. Things that trigger alarms.
Team 1 also made the statement that they only need short distance (100m). However, they may need to consider that two cars each doing 120kmh-1 will close a 100m gap in 1.5 seconds. If there's an emergency situation that needs action then, given mass and momentum, 1.5 seconds isn't going to buy you anything.
100m just isn't going to cut it I'm afraid - not for highway speeds at least.
As an aside: I love code samples. I love, even more, comments in code samples that explain what's happening.
void sensor_trig_HCSR04l(int pin)
{
LPC_GPIO2->FIOPIN &= ~(1 << pin);
LPC_GPIO2->FIOPIN |= (1 << pin);
delay_us(HCSR04_TRIG_DELAY);
LPC_GPIO2->FIOPIN &= ~(1 << pin);
left_start_time = lpc_timer_get_value(lpc_timer0);
}
Just not sure what's happening here...
Team 2 have some tangible goodness for those working with Curie: "Zephyr is destined to be the operating system of choice for the forthcoming Curie SDK...The only problem is that the documentation on the Zephyr project website is outdated and inconsistent". So they put together a guide to Zephyrizing the Curie. Awesome guys.
As a further aside Team 2 have posted a comment on the fundamental issue in IoT: Security. I am really, really hoping Team 1 focus on this, given that they are writing in C and are trying to control 2 tons of speeding death. Team 2 is building their stuff from the ground up to ensure things are secure. Read this and be worried.
The golden rule is to not try and build your own security. The fact that Team 2 needs to speaks volumes.
As another aside: if you've ever wondered how you write a system that will integrate multiple devices (some using Bluetooth, for instance) then follow their work on Iotivity. It's fascinating, and their discussion on basic Iotivity “Servlet” processing is brilliant.
Team 3 are continuing their work with MQTT to act as their pub/sub framework. Some good, commented code samples. As I said: I love a good code sample.
Team 3 have also posted some great tips for those looking to use Intel Curie boards in the Arduino IDE. Some tips in case you're having problems uploading skethes to your board.
Team 4 are fighting boards and sensors and APIs. And Zephyr. However, they've settled on using Apache Mynewt as their OS for their bluetooth smartcart system. It's all there, including a handy Docker container to get them going.
...and finally Team 5. Team 5 are getting down and dirty with the Arduino IDE on Linux with a handy step-by-step guide to getting you started. They then have to deal with some machanics: FFmpeg for getting their crop images to their gateway
One thing I was thinking about Team 5's efforts: they are reliant on fixed camara installations to detect crop issues. I'm fairly certain crop issues aren't going to conveniently pose in front of the limited number of fixed cameras, so why not make the cameras mobile? A fairly straightforward app to control a drone that would fly a course and take representative shots of a crop (flying on when the weather service says the conditions are OK) would require less hardware and provide greater coverage. And be way more cool.
Frankly I am concerned that IoT, as pushed by some pundits, is missing the point. We've had connected devices forever. The differences now are
- the devices are super cheap and there are tons of consumer-ready versions
- they are easy to program. .NET, Javascript, whatever you want
- They are connected to via internet gateways for (potentially) all to see
- we're now using them to lock our houses, control our webcams and furnaces, and collect our biometric data
So can I suggest that we step back a little and give equal focus to security and privacy. It's important.
cheers
Chris Maunder
|
|
|
|
|