25th of January 2014 is a milestone day to Softhinker who has converted from a sole proprietor to private limited company in Singapore. Meanwhile, the business scope has also been extended from a system integrator to a data mining provider in education.
Why education? Softhinker team has a strong belief that education is the key factor to civilization, and everyone has an equal right to receive education. To achieve this goal, data mining technique is one of the best way to optimize the teaching performance.
Devoting to education is a long journey with joyful experience, which has been practiced by great teachers and will be assisted by Softhinker from 2014 onward!
Vision: Everyone could learn anything in their own way.
Mission: Discover the learning pattern for everyone.
Values: Everyone has unique learning pattern.
Strategy: Subject by subject, the personal learning pattern is formed.
Up to Jenkins 1.460, its Subversion plugin 1.39 hasn't supported Subversion 1.7, so you may hit error like below screen shot :
Instead of waiting for the plugin to be updated, there is a workaround :
1. Install the latest CollabNet Subversion Client to the server, which provides svn command-line tool.
2. Put all maven commands into a shell, i.e. bat for Windows.
3. Use maven-antrun-plugin to execute that shell.
4. In Jenkins configuration page, just use 'antrun:run' as the 'Goals and options'.
It works because the shell will use the system variable where PATH includes the latest CollabNet path rather than the old svn path used by Jenkins.
Projects using XMPP server/client may encounter an issue that XMPP server will kill client connection if it's idle for some time. Of course, you can set it to never disconnect client but it puts another problem on board which is messages will be lost if client gets offline irregularly. XMPP server caches offline message only when the client status shows offline on server side. That's why in most of cases people will choose to set an idle time for client to be killed so that messages sent after disconnection of client will be queued in server side. However, how long the idle time should be set is still a case by case skill, which is actually out of the topic in this article.
What I'm going to showcase today is how to implement XMPP Pong on client side answering to XMPP Ping sent from server side to keep client alive when idle time is set. As you can see, XMPP Ping is the way the XMPP server is used to detect whether client is still alive or not, so according to XMPP Protocol
, two options you have to respond XMPP Ping : a) Pong b) Pong not supported.
As not every XMPP client library supports XMPP Pong, i.e. Smack API 3.0.0.beta1, below sample implementation is provided based on the 2nd comment in this discussion
1) Create class Ping extends IQ implements IQProvider
2) Create PingProvider
3) Create PingPacketFilter to filter out XMPP Ping sent from server side.
4) Create Pong based on the protocol
. In this case, we choose 'b' option which is to implement 'Pong not supported'.
5) Create PingPacketListener to answer XMPP Ping
6) Client responds to the server
At this point of time, you should be able to see the IllegalArgumentException thrown on server side, i.e. OpenFire, as below shown :
This exception is designed and acceptable according to the protocol, so it should good enough to keep client connection alive.
On 3rd of October 2011, Apple announce its Mobile Device Management(MDM) reference available on iOS provisioning portal. However, the sample code in the reference is fragmentary, especially on 'MDM Vendor CSR Signing Overview' section, which is to generate pList.
Softhinker works out below guidline to facilitate developers on pList generating process :
- There are two roles involved in the entire process : vendor
- As a vendor,
- create a CSR using any toolkit, i.e. KeyChain Access on MacBook, then export private key as 'vendor.p12'
- select 'Certificates' on the left navigation bar, and click 'Other' tab on the center.
- follow the instruction on that page, and upload the CSR you created.
- then the certificate for you as a MDM vendor will be available to download on the 'Other' tab. And download it.
- execute below openssl command to convert MDM vendor certificate, WWDR certificate, and Apple root certificate to PEM format one by one :
openssl x509 -inform der -in mdm_identity.cer -out mdm.pem
openssl x509 -inform der -in AppleWWDRCA.cer -out intermediate.pem
openssl x509 -inform der -in AppleIncRootCertificate.cer -out root.pem
- As a customer,
- create a CSR using any toolkit, i.e. openssl :
openssl genrsa -des3 -out customerPrivateKey.pem 2048
openssl req -new -key customerPrivateKey.pem -out customer.csr
- convert customer.csr to der format :
- Then use the attached Java program to generate encoded plist, and upload to https://identity.apple.com/pushcert/
openssl req -inform pem -outform der -in customer.csr -out customer.der
- remember to replace the placeholder in the package with your own ones :
- please note that generated plist.xml is not the one to upload, plist_encoded is.
customer.der, vendor.p12, mdm.pem, intermediate.pem, root.pem
Currently, iOS MDM Push Cert portal has a problem so that all plist uploaded will get a 'Invalid Certificate Signing Request', and a fix is supposed to be installed on January 2012.
Please like or +1 if you find it helpful. Thanks!
This is the final post of this Series.
10. Google Apps helps reduce the risk of data breaches
The use of laptops, smartphones, tablets and other mobile devices increases the risk of data breach if you're using traditional application which stores a local copy of your data, especially when mobile devices get lost or stolen, like what happened to Hong Kong star Edison Chen.
Google Apps can help reduce the risk of a data breach by limiting the data that is stored on your devices. When you check email or work on a document in a browser with Google Apps, the data is stored in our data centers, not on your device. That means that if your device gets lost or stolen, there is lower overall risk of a data breach. Similarly, if you collaborate with others in Google Docs, you don’t need to send them a copy of the document. You can enable and disable access to the document with a simple set of sharing controls and your collaborators access it from their browser. The document does not need to be stored locally on their device for them to collaborate on it.
For those times when you want to access Google Apps but you don’t have an Internet connection, we recently released an offline capability for Gmail and for Google Docs. The offline capability does involve some local data storage on devices. The amount of stored data is likely to be smaller as only a limited amount of documents and email are synchronized to the device for offline access. If you decide that this local data storage poses a risk, you can easily disable offline access.
As a Google Apps Authorized Reseller, Softhinker hopes you gain confidence on Google Apps solution through this series of posts, and we'd like to hear from you for further discussion.
7. Google Apps data protections - verified by third parties
In such a world where Cloud Computing is being talked everywhere, how do you distinguish who is the trusted Cloud Computing provider?
Cloud computing companies use the the SSAE 16
Type II audit, and its international counterpart ISAE 3402
Type II audit, to document and verify the data protections in place for their services. These auditing standards are defined by the The American Institute of Certified Public Accountants (AICPA) and the the International Auditing and Assurance Standards Board (IAASB), respectively. These audit standards have replaced the SAS 70 Type II audit, which Google Apps first completed in 2008
. In Google's audits, they specify the confidentiality, integrity and availability controls that our customers are most concerned about, which are then verified by our auditors. Google recently announced that they’ve successfully completed the SSAE 16 and ISAE 3402 Type II
audits for Google Apps, Postini services, Google Apps Script, Google Storage for Developers and Google App Engine.
Google Apps for Government has also received Federal Information Security Management Act (FISMA)
certification from the U.S. Government. The FISMA certification includes a rigorous evaluation of the security processes and data protections in place in Google Apps for Government and is required by U.S. federal government customers, who must comply with FISMA by law.
Just $5/user/month will enhance your business with edge technology powered by Google, and Softhinker
provides a hassle-free service to help your company equiped with excellent Google Apps!
6. New apps status dashboard improves visibility
Do you know what's the best merit of Google products I like? Open.
Merely sharing source codes to the world is not open in my dictionary. Google shares more than that. App status is one of what Google opens to the world, no matter the status is good or bad, though which users know how long is the downtime for Gmail recently, or was there a disruption or outrage for Google Sites?
Please don't regard this innovation as redundant or insignificant, especially when you're choosing which service/product is worth to invest. The best evidence is the statistics of its history, isn't it? Then how many service providers out there dare to provide the real app status to all of the world? Many of them just want to polish a beautiful financial report to the stock holders, rather than tell the truth. Google has the confidence to its technology, so it's open.
Let's take a look at some real data to gain more feeling. Last year, Gmail was up and running 99.984% of the time, and in the first half of 2011 Google has delivered 99.99% availability—that’s less than 5 minutes of downtime, on average, per month. A new App Status Dashboard
gives you accurate information faster, which can be used to evaluate Google products before investing on it.
Once your confidence is established, please drop us an email
, and Softhinker
would like to bring amazing Google Apps solutions to your organization!
5. Disaster recovery - built right in to Google Apps
Disaster recovery of business data is, to some belief, a topic that only big company should consider, while oppositely I totally disagree with this point of view.
To some extent, those giat companies are so robust that it's contrastively easy to recover from the critical data lost. Well, how about small/medium enterprises? Can SMEs afford data disaster? Maybe just one time of data lost is enough to kill a start-up business, isn't it?
So to my opinion, it's equally important for both big boys and small players in terms of disaster recovery.
Then question is how to establish a trusted and cost-effective disaster recovery plan?
The effectiveness of a disaster recovery plan is commonly measured in two ways: Recovery Time Objective (RTO) and Recovery Point Objective (RPO). RTO measures how long before users can access systems in the event of a failure. RPO measures how much of a time gap exists when the data is restored. Businesses that have invested lots of time and money in disaster recovery preparation are typically able to set RTO and RPO goals at a few hours or less for critical systems, with the cost increasing as those timeframes decrease. For other businesses that haven’t invested at that level, RTO and RPO can stretch into hours or days. And in extreme cases, if disaster strikes, some businesses just have to start over.
Google Apps offers a better way, with robust disaster recovery capabilities built right in. Our RPO design target is zero data loss and our RTO design target is instant failover. This means that if there is a disaster or disruption that affects one of our data centers, we are able to shift users to an alternate data center, so they can can continue working uninterrupted. And while no disaster recovery solution from any provider is perfect, Google is proud of the benefits customers gain.
The most attractive part of how to leverage on this excellent solution is : drop softhinker
an email today!