If you could read the internal employee message boards/mailing lists at one of the largest software companies... you'd see the same thing... the senior engineers hardly ever ask any questions. I think it's simply because they are the most experience problem solvers. Almost any problem can be solved with a debugger and 1 experenced engineer.
It's an interesting idea but I highly doubt you'll see any change in the numbers.
Are you working with some other dataset I don't know about? Are you seeing high rep members creating sockpuppets to ask questions?
Hmmm, you have a point, but I suspect that it does more harm than good. Ya gotta try though.
Primarily I agree. I ask very few questions and when I do have something I might ask about, I try to do as much as I can to diagnose the issue and give a full accurate description -- often with the result that I solve it myself. And maybe write a Tip.
But when there is something that still eludes me, I have no issue with asking -- I so want those other two platinums!
Maybe give members above a certain reputation the option to obfuscate their name?
Maybe similar to the option I have of posting as myself or as my Group?
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.
It does not solve my Problem, but it answers my question
"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
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.
Who asks not stray
On the other hand, how can i report a user who's posting spamm on QA forum?
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"
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!
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
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.
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.
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,
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.
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 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 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.
Last Visit: 31-Dec-99 19:00 Last Update: 22-Feb-18 7:03