Its been several years since assembling those cassette players to make a few bucks! The sight of a Raspberry Pi (gifted to them by our CTO!) at our pantry where a couple of guys had connected it to the TV got me curious to start looking at it.
A little reading and I realized it was a computer and it had GPIO. Several years I had kick started stuff on GPIOs and then stopped due to the relatively huge cost of the GPIO chips but now here is a computer with a GPIOs!
So, ordered one and couldn't wait it to arrive.
Day 1: Loaded linux onto it and started working it furiously to get my first home security system to be done. Wrote a piece of code (well I think I should say copied here) in Python to interact with www.privateeyepi.com. All this does it read a particular GPIO pin. If the values changes it updates www.privateeyepi.com which in turn sends out an email (all for free). If you have access to a sms gateway you could add an sms feature as well!
Day 2: After tasting some sucess on Day 1, I decided to move onto some home automation! What if I could switch on lights at home from anywhere in the world. Not sure of the practical usefulness but sounds cool? So, now got the Web2Py framework on Pi. Tested the connectivity from a mobile, ordered a 5 channel remote to be able to switch on/off appliances) and off to catch some sleep
Day 6: Connected the PI to the remote to simulate on/off by using the GPIOs and now I an switch on/off appliances through the web!
Day 7: Managed to connect an old USB camera to the PI. Played around with OpenCV for facial recognition. Able to recognize faces (not identify them yet). Ordered the camera module for the PI and the goal is to be able greet / shoo off visitors using facial recognition!
I have not pasted code here since all the above is available as open source on the net, feel free to ping me for help!
Monday, July 22, 2013
Saturday, February 25, 2012
Windows Phone 7
Since my wife's phone died, had to get a new phone and I used this opportunity to try out a Windows Phone 7 (Samsung Omnia) so that I could try my hand at developing some apps.
The last time I tried out a Windows Phone or rather Windows Mobile was a few years ago and deploying an app was a breeze. So, started off with the same expectation.
Did some reading and figured out that I needed the Windows Phone SDK, Zune (to connect the phone to Windows).
Connected the phone and Zune started up but realised that my live id had limitations and got the following error "The location setting for your Windows Live ID doesn't match the setting for your computer (United States)." Changing regional settings and locale did not help. There is a codeplex tool to fix this - http://localizune.codeplex.com/.
Now, decided to test some apps and realized you actually need to pay $99 even if you just want to test out some apps on your phone! So, gone are the days when you could actually write code and hit F5 to deploy it to your mobile. Once you have registed with App Hub (by paying $99), you need to register the phone.
Launched the Windows Phone Developer Registration tool and get another error message "Unable to connect to phone. Please check that the Zune software is running and that Zune's sync partnership with your phone has been established". After spending almost 2 hours did the customary reinstall (of Zune) and was able to register the phone.
Now the phone is ready to accept custom applications!
The last time I tried out a Windows Phone or rather Windows Mobile was a few years ago and deploying an app was a breeze. So, started off with the same expectation.
Did some reading and figured out that I needed the Windows Phone SDK, Zune (to connect the phone to Windows).
Connected the phone and Zune started up but realised that my live id had limitations and got the following error "The location setting for your Windows Live ID doesn't match the setting for your computer (United States)." Changing regional settings and locale did not help. There is a codeplex tool to fix this - http://localizune.codeplex.com/.
Now, decided to test some apps and realized you actually need to pay $99 even if you just want to test out some apps on your phone! So, gone are the days when you could actually write code and hit F5 to deploy it to your mobile. Once you have registed with App Hub (by paying $99), you need to register the phone.
Launched the Windows Phone Developer Registration tool and get another error message "Unable to connect to phone. Please check that the Zune software is running and that Zune's sync partnership with your phone has been established". After spending almost 2 hours did the customary reinstall (of Zune) and was able to register the phone.
Now the phone is ready to accept custom applications!
Thursday, June 16, 2011
Sharing phone's internet connection with laptop
This one is probably easy but it was tricky for me since I had to connect to the internet using my phone's GPRS connection as my broadband modem had gone bust. I say tricky because I had no access to the internet and hence no search engines and the browser on the phone is not friendly. This explanation is for a Windows 6.1 Mobile and Windows 7 Pro combination
So, here we go
Pair the phone with the laptop / desktop
On the phone click on start --> programs --> Internet Sharing.
Then choose Bluetooth Pan for the PC Connection. Choose the network connection which connects your phone to the Internet and click Connect
Now click on the bluetooth icon on the status bar and choose Join a Personal Area Network.
Highlight the Phone on the bluetooth devices list. From the top menu choose "Connect Using --> Access Point".
Happy Browsing!
So, here we go
Pair the phone with the laptop / desktop
On the phone click on start --> programs --> Internet Sharing.
Then choose Bluetooth Pan for the PC Connection. Choose the network connection which connects your phone to the Internet and click Connect
Now click on the bluetooth icon on the status bar and choose Join a Personal Area Network.
Highlight the Phone on the bluetooth devices list. From the top menu choose "Connect Using --> Access Point".
Happy Browsing!
Audience targeting vs Permissions in SharePoint
Can audience targeting be used for permissions i.e., control what the users sees? I have seen most folks get this wrong. Audience targeting cannot be used for permissions and here is the reason.
Audience target is used to target content to a particular audience but it does not prevent the user from navigating to the content.
Audience target can be used to customize the content on the page based on the audience profile but if the user knows the path to the content they can still navigate to it and view it unless it is controlled with permissions
Audience target is used to target content to a particular audience but it does not prevent the user from navigating to the content.
Audience target can be used to customize the content on the page based on the audience profile but if the user knows the path to the content they can still navigate to it and view it unless it is controlled with permissions
Sunday, November 7, 2010
SharePoint setup on a cross-domain one way trust environment
Its been quite a while since I have written something technical. Either too busy or did not find anything challenging enough. Well, here is one that was fairly challening considering I am not a SharePoint Administrator.
Requirement: The client had two domains - A and B. There is a one way trust between A and B such that B understands everything in A. The SharePoint instance is on B i.e., Users of A can logon to B but not vice versa.
The following solutions were possible -
1) Setup claims authentication using ADFS. Probably the best approach but not sure how the credentials in B would get validated since the trust is from A to B.
2) Imports users of A into B and keep them in sync using Microsoft ForeFront Identity Manager (FIM). This would have cost implications as FIM is not free.
3) Use AppFabric Access Control. This is relatively new and not played around with it yet.
4) Have NTLM authorization right through by using the ForeFront Identity Manager service available out of the box. This is not the best approach because of possible double hop issues later on but we decided to go ahead with this as currently authorization at the DB level was not a requirement and service accounts could be used to authentication into the DB.
Having decided on Approach 4 we decided to try this out on a VM setup. We created 2 domains A and B, created the one way trust and ensured that once user from A was added to B, he was able to logon and users of B should be able to logon to A.
Once this was done, we had to install the ForeFront Identity Manager service and then run the Profiler Service in SharePoint. This imported the users from A into B. We then added a user in A on one of the sites in B. So, things looked hunky dory until this point. But when we tried to logon to the site with the credentials of the User in A a blank page was displayed and the event logged had a security exception - Bad username/password. After a bit of thought, it was clear that the credentials were not getting validated. Reason - the service account was not able to validate the username/password from domain A! We resolved the issue by using the credentials of User in A for the service account of the Profiler service in SharePoint. Possibly not the best approach but since we have SharePoint on Domain B, I guess there is no other way out!
Comments/suggestions welcome and appreciated.
Requirement: The client had two domains - A and B. There is a one way trust between A and B such that B understands everything in A. The SharePoint instance is on B i.e., Users of A can logon to B but not vice versa.
The following solutions were possible -
1) Setup claims authentication using ADFS. Probably the best approach but not sure how the credentials in B would get validated since the trust is from A to B.
2) Imports users of A into B and keep them in sync using Microsoft ForeFront Identity Manager (FIM). This would have cost implications as FIM is not free.
3) Use AppFabric Access Control. This is relatively new and not played around with it yet.
4) Have NTLM authorization right through by using the ForeFront Identity Manager service available out of the box. This is not the best approach because of possible double hop issues later on but we decided to go ahead with this as currently authorization at the DB level was not a requirement and service accounts could be used to authentication into the DB.
Having decided on Approach 4 we decided to try this out on a VM setup. We created 2 domains A and B, created the one way trust and ensured that once user from A was added to B, he was able to logon and users of B should be able to logon to A.
Once this was done, we had to install the ForeFront Identity Manager service and then run the Profiler Service in SharePoint. This imported the users from A into B. We then added a user in A on one of the sites in B. So, things looked hunky dory until this point. But when we tried to logon to the site with the credentials of the User in A a blank page was displayed and the event logged had a security exception - Bad username/password. After a bit of thought, it was clear that the credentials were not getting validated. Reason - the service account was not able to validate the username/password from domain A! We resolved the issue by using the credentials of User in A for the service account of the Profiler service in SharePoint. Possibly not the best approach but since we have SharePoint on Domain B, I guess there is no other way out!
Comments/suggestions welcome and appreciated.
Subscribe to:
Posts (Atom)