Monthly Archives: July 2014

Judge orders Microsoft to turn over data held overseas 1

This entry was posted in Computer Security News on by .

In a case closely watched in the United States and overseas, a federal judge in New York held Thursday that Microsoft must comply with a U.S. search warrant to turn over a customer’s e-mails held in a server overseas.
Judge Loretta Preska — in a surprise ruling from the bench — upheld a magistrate judge’s opinion in December ordering the Redmond, Wash., company to allow federal authorities to obtain copies of the data, which is stored in Ireland.

Source: www.washingtonpost.com

Ryan Seifert‘s insight:
This is really a painful ruling for cloud providers operating in the States. While it was still possible to comply with the requests before; there were substantially more steps involved (Mutual Legal Assistance procedures). This ruling sidesteps those steps to grant quicker access. 

The major concern of the ruling is that it could easily push international companies to select cloud hosts that are not US based (for instance a medical software service selecting to host with an Open Stack cloud provider rather than AWS or Azure).

 

On a good note, Microsoft is appealing again and the judge actually suspended her order until the appeal is decided. It is not surprising to see Microsoft fight this; their cloud services have been quickly growing in the last couple years. I would expect to see Amazon and Google take the same position; as both also provide cloud base services.

How I ended up conducting the most successful technical interviews with a single question 3

This entry was posted in Leadership and Management News on by .


How I ended up conducting the most successful technical interviews with a single question

i conducted my first tech interview in 2008. at that time, the company already had a working process that i followed: interviews were 1 hour. the candidates would have 30 minutes to answer a 15 questions quiz. then we would spend 15 minutes talking about their answers plus an additional 15 minutes answering questions about the job. i quickly realized how terrible that questionnaire was.

 

 

 

Ryan Seifert‘s insight:

An interesting article for me; since I believe I started interviewing roughly the same time. We took similar paths (but I did not attempt to automate the process); migrating from some technical questions to a much more open ended process.

 

I recall one particularly rough interview; where after I started into my 10 technical questions the candidate quickly grew agitated. A agitated interviewee was a wholly new experience for me; I felt the blood drain from my face as he yelled, “I WON’T TAKE A TEST!” over the phone. Trying to regain my composure and calm him down; I let him know there was no score or grade. The questions are really discussion points to see how you code and design. The statement did little to soothe him; as I only heard a louder, “I WON’T TAKE A TEST!” in response. I decided at this point he was not a good cultural fit and started to bring the interview to a close. My salutation of “I appreciate your time and am sorry if I offended you. If you have any other questions for me, please ask.” was met with a quick “Click” and dial tone. Needless to say; this did spark a review of my interview process.

 

While the author coalesces on a single question, I have left mine at two:

  • What has been your favorite project to build and what challenges did you face during the development?
  • In your opinion what has been the most interesting bug you have had to locate and squash?

 

The follow up discussions on these questions easily leads into some technical questions on the language they used and which design patterns they implemented. More importantly it allows you to see which areas of software they are most passionate and interested in. Finding great talent and putting them into an environment where they can flourish will ensure excellent results. Switching to this open ended format took me from around a 20% success rate (ouch) to more than 80%; which have failed due to reasons other than technical prowess.

 

Looking back at the interview experience I touched on earlier; how much different could it have gone if I had asked my 2 questions and delved deeper into a subject near to them.

Cross-Platform Mobile Development: PhoneGap vs Xamarin 2

This entry was posted in Development News Tech on by .

3 different operating systems, 3 separate languages and development environments, and counting.  To be able to cater to all of these operating systems natively, mobile app developers need to have someone able to be an expert in each of these programming languages and also be an expert in the nuances of how each mobile operating system works.  Task lifecycles, multi-threading, memory limitations, garbage collection, etc.

Thus to have 1 app developed in its native language and environment will take 3 times as long. Thus tripling the cost of development.

Ryan Seifert‘s insight:
An interesting article on which platforms to use for different projects. We have been scouring the current state of cross-platform development before launching into a new mobile application; but we have run into many questions on which system to use.

This quick read does a fantastic job listing the strengths and weaknesses of these two popular platforms. I walked away from the article with a better understanding of the platforms and even a general overview of the architecture involved in the development.

The closing argument for utilizing Xamarin for larger projects was very sound and a point not often encountered in comparison articles. I am looking to run a couple small apps to gain some first hand experience on them; but with the size of the projects and the possibility for growth the choice for now seams clear.

Why do dynamic languages make it difficult to maintain large codebases?

This entry was posted in Development News on by .

Dynamic languages have costs associated with them that static languages don’t. Let me begin by saying that it is hard to maintain a large codebase, period. Big code is hard to write no matter what tools you have at your disposal. Your question does not imply that maintaining a large codebase in a statically-typed language is “easy;” rather the question presupposes merely that it is an even harder problem to maintain a large codebase in a dynamic language than in a static language. That said, there are reasons why the effort expended in maintaining a large codebase in a dynamic language is somewhat larger than the effort expended for statically typed languages.

 

 

Ryan Seifert‘s insight:
This article touches on a topic I have been wrestling with. I keep returning to a rule of thumb: if it is a prototype, under 300 lines of code, or a single (or very limited) use program; dynamic language is easily the best choice. There is a reflection point where static languages make maintaining code bases easier; but that point is much harder to define.

I find it interesting how some large projects written in Javascript have chose to attack the increase codebase issue. We have seen inclusion of type-checking (Typescript), modules (jQuery et all), and much stronger test suites. Many of these techniques are common in static languages and have been used to great success in maintaining codebases.

Unfortunately, the article does not touch on if and when a module rewrite would be useful. At which point does the overhead of leveraging a dynamic language incur a cost greater than a migration to a language easier to maintain or which a better tool set exists? The emergence of language agnostic testing frameworks have reduced this barrier substantially (assuming tests provide significant code coverage). I am interested in seeing if language migrations start to occur at a larger rate (perhaps as language-to-language conversion becomes more common). Quick, painless, and verifiable language migrations would be a great boon for any project.