|
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
|
|
|
|
|
Over the course of eight weeks, five teams will develop, prototype and journal their progress using the Intel® commercial IoT developer Kit
Team 5[^] has given us some more info on how they are approaching their goal of remote disease identification. It's a basic, common-sense approach: Have a bunch of cameras trained on a crop to monitor and identify diseased foliage in real time. If anything is found then the farm will be sent information on how to deal with the issue. If anything new is found then the images will be catalogued, identified and added to the library.
They have my attention with their use of machine learning to classify crop states using a well defined set of signals. Artificial intelligence and machine learning are, by far, the hot topics this year and it's nice to see it be used for soemthing other than driving cars and predicting stock prices. Priorities, anyone?
Team 4[^] have up'd the hardware count for their proximity based advertising system. They did get down and dirty with a bit of code in their blog, but even talking dirty like that isn't going to sway me. An interesting point they've raised is that managing a messaging system via proximity is going to require very, very careful tuning of the signal. Once a beacon is out of range the recievers will need to know this. No point getting a message about a can of tomatoes 3 aisles over.
But what about a message from a box of cornflakes on the other side of the shelf? I'd be interested in seeing how they handle that one.
Team 3[^] is thinking about communication for their remote doctor application. They are based in India and in remote areas not everyone has a smartphone or even an internet connection. The same can be said of countries such as Australia. As such they've settled on SMS as their delivery system of choice. Tech stack will be Javascript, MongoDB, node, with IBM Bluemix as the platform. No Azure or AWS?
Given that bandwidth (and phone batteries) are a limited resource they are focussing on a light messaging protocol via MQTT (Message Queuing Telemetry Transport). This is a lightweight M2M protocol specifically for IoT.
Team 2[^] has explained how easy it is to get Clojure running then shows precisely the opposite. This is 2016. This stuff should Just Work by now.Anyway, using nrepl means they can develop on their desktop while evaluating code on the target device.In any case they got that bit working and then moved on to porting IoTivity[^] to the platforms of choice. IoTivity enables device to device communication.
Team 1[^] is coming to grips with the reality of ad-hoc networks of devices travelling at 100kmh, not all in the same direction. They are trying to put together a system whereby vehicles will coordinate among themselves in order to not crash. A MongoDB style master-slace system just isn't going to cut it. My thought: An every-man-for-himself system based on every vehicle looking to avoid every other vehicle by "watching" what every other vehicle is doing. Basically what humans do: We focus on not hitting anything else and we watch (and anticipate) what others are doing to predict speed and location and not be there at the same time.
Vehicles can transmit velocity (speed and direction), acceleration, mass, yaw, available traction, general vehicle health and intended path constantly. Communication will need to be super-fast, but if everyone is saying basically "I'm headed that way and here's how fast I'd be able to stop" then everyone can keep out of everyone else's way.
I'm already sensing a pattern here. There are no standards for IoT. In anything. Each team is using a different stack, different protocols, different platforms. They are all, for the most part, using the same Arduino boards and Grove Starter Kit[^], yet there's no "standard" being followed. Add to that the plethora of backend webservices at their disposal, and then open it up to even more hardware and you have a problem if you're looking for the "right" way to do things.
Maybe Javscript will turn out to be IoT's BASIC. Maybe technology will continue to progress so rapidly that new standards simply aren't necessary and current (server) based technologies will transfer wholesale to embedded devices.
cheers
Chris Maunder
|
|
|
|
|
Chris Maunder wrote: Maybe technology will continue to progress so rapidly that new standards simply aren't necessary
|
|
|
|
|
Intel has launched a new Ultimate Coder Challenge[^] that follows the same structure as previous years: multiple teams, 8 weeks, 1 challenge.
This year's challenge is IoT: Who will create the next great commercial solution? Using the Intel commercial IoT development kit the challenges must come up with an idea - and an implementation - that truly defines what IoT is and means to us all.
Out of the gate I will admit I'm already heavily biased to an idea I've been spouting to all and sundry for years: a local wireless network for cars that would reduce to near zero the chance of collisions.
Team one[^] aka Team Whirlwind are working with Intel Edison and Dell Wyse[^] to create a highly distributed adhoc network modelled after MongoDBs Master-Slave model.
They will need to overcome issues such as network latency, basic network issues, interference, speed, and ultimately interfacing with a car so that the system actually does something. I hope they succeed. It's about time we had this.
Team Two[^], aka Team Geras, has the goal of diving deep into the behavioural patterns of those in their twilight years to look for correlations between behaviour and undesirable incidents. Does a hot day and a bout of lawn bowls result in more falls? Does high humidity and certain social interactions result in a case of the vapours?
This is a lofty goal and I worry that gathering and analysing enough data within the time of the contest will be difficult.
Code will be written in ClojureScript running on JerryScript. Because they want to. I write way too much Javscript (badly) and I swear we're all going to look back on the twenty-tweens and think "what sort of drunken haze were we in to think Javscript was a good idea for everything?"
Team Three[^], aka Team Iot Vaidya, are looking to create a standalone solution meant specifically for people living in remote places where there is shortage of doctors. The idea is that there's a dearth of medical support in many rural communities so why not automate some of the more pedestrian tests that can be done to get an initial good/bad diagnosis? Team Three will focus on a person’s ECG and pulse rate plus other vitals like temperature, Galvanic Skin Response. "A lot can be said by proper analysis of these parameters."
As a bit of a chronic cyclist this sort of stuff is right up my alley. I ride with my eyes glued on my heartrate, left/right pedal stroke balance, power output, cadence, calories burned and occasionally oxygen saturation and heomoglobin recruitment. Sometimes I even watch where I'm going. Having access to a wearable that would include things such as ECG, temp and galvanic skin response would be brilliant. Selfish, in that it's all about my cycling and not about saving lives (directly) but the applications for a solution such as Team Three is proposing go far and wide.
Team four[^], or Team Proximarket, have waxed lyrical about the physical web but their introduction scares me a little. Smartcart is a proximity based technology for retailers that, among other things, will reduce the impact of customer oversight. Oversight meaning "Excuse me: it looks like you forgot to pick up toilet paper. It's in aisle 3, 7.5m to your left." or "Escuse me: it looks like you're trying to leave the store without spending enough. We've talked to your car's infotainment system and it agrees you're not going anywhere until that shopping cart is nice and full"
If they win then I'll be the first to welcome our new robot overloads.
Team five[^]. Agro Hackers. Evidently "Agro hackers" means "deep understanding of farming for transformation". I'm Australian, and to me it means an "angry or hostile who breaks into the computer system of a company, government, etc.
But again maybe not. Team Agro Hacker is working to deliver a solution to crop disease and pest management using image processing and machine learning. You get the computer to take a peek at the leaves of a crop and have a good hard think about what could be wrong.
Admirable work, and increasingly important in a world rapidly growing. They have no, however, made it clear how this is an IoT solution. They'll need to clarify this to move ahead.
Let's see how things shape up next week.
cheers
Chris Maunder
|
|
|
|
|
Funny, I don't see Team Bob in the listed line-up. 
|
|
|
|
|
We've had a number of complaints that a member will spend a great deal of time crafting a response to a question in Quick Answers[^] only to hit the post button and find the question was deleted or closed while they were answering it.
In a perfect world everyone would agree on what's suitable for answering and what's suitable for closing, but our world is far from perfect. Effective today we've added a feature that will re-open a question that's been closed if someone posts an answer to that question.
We could have implemented question locks, but locks are messy.
cheers
Chris Maunder
|
|
|
|
|
We've launched a small change to Quick Answers[^]. When posting a question you get the usual "Subject" and "describe the problem" boxes, but we've also added a "What have you tried?" box that must be filled in before you can post your question.
It makes it harder to post a question (barely) by forcing the poster to think a little about what they've done so far. It allows those answering to avoid things already tried and suggest new ideas. It will also, possibly, act as a self-identifier of those too lazy to explain their problem to those eager to help.
We'll see. It's all about trying something new.
cheers
Chris Maunder
|
|
|
|
|
Sounds cool Chris. 
|
|
|
|
|
Thanks Chris, Its really good move. It helps questions to become more self-explanatory and avoid same solution that already tried by OP, Additionally it avoid spam post and lazy questions. Most of the time in CP, I have seen questions with title "Please solve it urgently" or "error in c# application" with same description as title. (though I tried to "IMPROVE" it but due to less description, it remains unclear)
Members should take its benefits and can improve the question quality to help them resolve quickly.
Finally "More time to explain question will help to reduce time to resolve it"
Find More .Net development tips at : .NET Tips
The only reason people get lost in thought is because it's unfamiliar territory.
|
|
|
|
|
We've launched a new article section[^] that will allow you to contribute articles containing live JavaScript. At this point we're restricting it to just online tools in order to test the idea and get community feedback. If things go we'll we'll look to extend this to all article sections.
cheers
Chris Maunder
modified 5-Aug-15 12:19pm.
|
|
|
|
|
I am not sure whether articles require this or not (perhaps after reading a few it does seem a good idea). But I am very much considering this to be applied to Quick Answers' answering box (or to any post editor, including this reply editor). Rather than uploading the data to servers and then formatting it after every character insertion, you should add the JavaScript power on the client-side.
As far as the links are concerned (copy/pasting the link). I would recommend, instead of sending a request to get the title. You should leave that to server when poster is done editing the post to update the content of that link to a title (if from CodeProject). Like Markdown! It would make it a lot better. Plus, it would give you an opportunity to add link titles for posts from other sites by reading their <title> tag.
For example, just to edit this messages for you, I have sent like 15 requests with 1kb+ size. For me, it doesn't matter, but for someone with a metered connection, it does. This size also increases with the increase of characters. (Right now it is 2.3kb and growing for each request).
The sh*t I complain about
It's like there ain't a cloud in the sky and it's raining out - Eminem
~! Firewall !~
|
|
|
|
|
The reason we do Ajax calls for formatting is because we want to ensure the colourisation is done properly. We could simply skip the formatting, or use something like syntaxhighlighter to do some rough colourising. It's been discussed many times.
Another fly in the ointment is that not all markdown implementations are the same. I'm still trying to find an implementation that suits our needs, and trying to find a matching pair Javascript implementation could be a challenge.
If you're worried about postback size then uncheck the "Show a live message preview as you type (not available < IE9)" checkbox in your Settings[^] (under the Forums tab)
cheers
Chris Maunder
|
|
|
|
|
With regret we've abandoned using CommonMark to render our messages.
CommonMark is meant to fix the issues inherent in other Markdown implementations while being true to the core ideas of Markdown. Basically: it should just work, there should be no surprises, and it should work with existing HTML. Markdown / CommonMark handles the main gruntwork of text formatting and when you need some fine tuning just throw in some HTML and you're good to go.
Unfortunately CommonMark handles PRE (i.e. Preformatted) blocks in a manner that simply doesn't work for us. A PRE block should (at least in my book) allow you to enter text and have the formating maintained as-is. On CodeProject we cheat a little[^] and allow things like B, EM and U tags for those who want to highlight sections of code, but beyond that what is entered is what appears.
In CommonMark a PRE block that contains text that is indented 4 spaces will trigger the creation of a <pre><code> pair that wraps the indented block as if it were a code sample. Code samples are often indented, so whenever you paste code into a PRE block then you'll more than likely get nested PRE blocks.
This just doesn't work for us. We love what CommonMark is doing to provide consistency, but that's just seems an odd decision. For now we're disabling Markdown in Quick Answers and reverting back to MarkdownSharp.
This makes me sad.
Previous message:
We announced the introduction of Markdown[^] into the forums and Quick Answers a while ago, but we were never truly happy with the implementation of the Markdown processor in use. Ambiguities, lack of standards, and poor performance of the Markdown transformer were niggling annoyances.
CommonMark[^] seeks to address these issues by introducing an unambiguous standard spec that developers can work against to create fast, efficient and reliable Markdown processors[^].
The syntax is slightly different[^] to that of Markdown, but the changes are small enough that it should, hopefully, not cause any problems. As always if you do come across issues let me know and we'll season to taste.
cheers
Chris Maunder
|
|
|
|
|
It doesn't help spelling though, I see.
What do you get when you cross a joke with a rhetorical question?
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
Do questions with multiple question marks annoy you???
|
|
|
|
|
Yuo think not?
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
We now support Gravatars for your profile picture to help reduce the pain in maintaining your latest profile selfie (or professional studio shot - whichever). Just setup (or update) your Gravatar pic and then on your settings page select "Use my Gravatar", hit update, and you're done.
cheers
Chris Maunder
modified 11-May-15 9:42am.
|
|
|
|
|
hyperlink is invalid/incorrect/typo error for Gravatar. 
We should be building great things that don't exist-Lary Page
|
|
|
|
|
Thanks - fixed.
cheers
Chris Maunder
|
|
|
|
|
Nice. Updated my profile.
Small issue with your post Chris. Please update.
Quote: We now support Gravatars
Here the URL of Gravatars has / instead of .(dot).
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
