From jacoby.david at gmail.com Mon Aug 18 04:59:57 2014 From: jacoby.david at gmail.com (jacoby.david at gmail.com) Date: Mon, 18 Aug 2014 04:59:57 -0700 (PDT) Subject: [Purdue-pm] REMINDER: Purdue Perl Mongers meets TOMORROW! Message-ID: <53f1eabd.4508320a.352a.ffff99b5@mx.google.com> Greetings! This is an automated message to announce that Purdue Perl Mongers will meet TOMORROW at 11:30am in WSLR 116. Generally, we discuss computing, dynamic languages, Purdue and the overlap of those three (plus whatever else comes up) until Noon, then have one or more more formal presentations. We don't always discuss Perl -- we have had presentations on Python, Javascript, HTML4, Selenium, and many other topics -- so if you are not an experienced Perl user, there's still a place for you. Check our Twitter feed (@purduepm), our Google+ Community (https://plus.google.com/communities/100780979348959606696) or our web page (http://pm.purdue.org) for more information. From derrick at csociety.org Mon Aug 18 06:27:24 2014 From: derrick at csociety.org (derrick) Date: Mon, 18 Aug 2014 09:27:24 -0400 Subject: [Purdue-pm] REMINDER: Purdue Perl Mongers meets TOMORROW! In-Reply-To: <53f1eabd.4508320a.352a.ffff99b5@mx.google.com> References: <53f1eabd.4508320a.352a.ffff99b5@mx.google.com> Message-ID: <53F1FF3C.6040008@csociety.org> I'm going to try to have a presentation ready on how people can incorporate design patterns into their selenium webdriver page objects. dsk On 08/18/2014 07:59 AM, jacoby.david at gmail.com wrote: > Greetings! > > This is an automated message to announce that Purdue Perl Mongers > will meet TOMORROW at 11:30am in WSLR 116. > > Generally, we discuss computing, dynamic languages, Purdue and the > overlap of those three (plus whatever else comes up) until Noon, > then have one or more more formal presentations. We don't always > discuss Perl -- we have had presentations on Python, Javascript, > HTML4, Selenium, and many other topics -- so if you are not an > experienced Perl user, there's still a place for you. > > Check our Twitter feed (@purduepm), our Google+ Community > (https://plus.google.com/communities/100780979348959606696) > or our web page (http://pm.purdue.org) for more information. > > > _______________________________________________ > Purdue-pm mailing list > Purdue-pm at pm.org > http://mail.pm.org/mailman/listinfo/purdue-pm > From alexmcn at tds.net Wed Aug 20 08:29:32 2014 From: alexmcn at tds.net (Ken mcNamara) Date: Wed, 20 Aug 2014 11:29:32 -0400 Subject: [Purdue-pm] Picking a programmer Message-ID: <86712BE1-622C-4C4D-9424-A7D2457555D3@tds.net> If you needed to hire a programmer for an important project... What do you look for? Multiple languages? System agnostic? Prefers programming to eating/sleeping? What qualities make a good programmer? Any thoughts would be appreciated. KenMc From jacoby at purdue.edu Thu Aug 21 07:39:16 2014 From: jacoby at purdue.edu (Dave Jacoby) Date: Thu, 21 Aug 2014 10:39:16 -0400 Subject: [Purdue-pm] Communication Between Spotlights Message-ID: <53F60494.6040905@purdue.edu> I remember a few years ago, Mark Senn talked through an idea of networking stoplights so they can communicate with each other, handling traffic more efficiently and such. Turns out they are networked wirelessly. And they can be hacked because of it. http://arstechnica.com/security/2014/08/researchers-find-its-terrifyingly-easy-to-hack-traffic-lights/ -- Dave Jacoby Developer, Purdue Genomics Core Lab http://web.ics.purdue.edu/~djacoby/ 394 days using standing desk From derrick at csociety.org Thu Aug 21 08:11:43 2014 From: derrick at csociety.org (derrick) Date: Thu, 21 Aug 2014 11:11:43 -0400 Subject: [Purdue-pm] Picking a programmer In-Reply-To: <86712BE1-622C-4C4D-9424-A7D2457555D3@tds.net> References: <86712BE1-622C-4C4D-9424-A7D2457555D3@tds.net> Message-ID: <53F60C2F.1040107@csociety.org> I'll throw out the ideas of: 1. problem solving 2. curiosity 3. creativity I'm interested in curiosity and creativity because requirements for projects are rarely well defined with first given. There ends up being a few revisions/clarifications as each side interprets them. Being able to figure out what people really want and tease out the use cases seems to be more of an art than a science. Understanding multiple programming paradigms (functional, procedural, object oriented, vector) is more interesting to me than knowing multiple languages. I feel that language is a lot about knowing the correct syntax, a little about understanding peculiarities between languages. Knowing how to think through a problem using a paradigm allows you to approach a problem from many angles, weighing the benefits of each. dsk On 08/20/2014 11:29 AM, Ken mcNamara wrote: > If you needed to hire a programmer for an important project... > > What do you look for? > > Multiple languages? > > System agnostic? > > Prefers programming to eating/sleeping? > > > What qualities make a good programmer? > > Any thoughts would be appreciated. > > KenMc > _______________________________________________ > Purdue-pm mailing list > Purdue-pm at pm.org > http://mail.pm.org/mailman/listinfo/purdue-pm > From mdw at purdue.edu Thu Aug 21 08:24:49 2014 From: mdw at purdue.edu (Mark Daniel Ward) Date: Thu, 21 Aug 2014 11:24:49 -0400 Subject: [Purdue-pm] Picking a programmer In-Reply-To: <53F60C2F.1040107@csociety.org> References: <86712BE1-622C-4C4D-9424-A7D2457555D3@tds.net> <53F60C2F.1040107@csociety.org> Message-ID: <53F60F41.6020703@purdue.edu> I think it's important that the person can communicate well. They need to be able to work with other people to understand the content of the programming task, the motivation, the impact, the users, etc. They also need to be able to document their code, if you want a really high quality product. On 8/21/14, 11:11 AM, derrick wrote: > I'll throw out the ideas of: > > 1. problem solving > 2. curiosity > 3. creativity > > I'm interested in curiosity and creativity because requirements for > projects are rarely well defined with first given. There ends up being > a few revisions/clarifications as each side interprets them. Being > able to figure out what people really want and tease out the use cases > seems to be more of an art than a science. > > Understanding multiple programming paradigms (functional, procedural, > object oriented, vector) is more interesting to me than knowing > multiple languages. I feel that language is a lot about knowing the > correct syntax, a little about understanding peculiarities between > languages. Knowing how to think through a problem using a paradigm > allows you to approach a problem from many angles, weighing the > benefits of each. > > dsk > > > On 08/20/2014 11:29 AM, Ken mcNamara wrote: >> If you needed to hire a programmer for an important project... >> >> What do you look for? >> >> Multiple languages? >> >> System agnostic? >> >> Prefers programming to eating/sleeping? >> >> >> What qualities make a good programmer? >> >> Any thoughts would be appreciated. >> >> KenMc >> _______________________________________________ >> Purdue-pm mailing list >> Purdue-pm at pm.org >> http://mail.pm.org/mailman/listinfo/purdue-pm >> > > _______________________________________________ > Purdue-pm mailing list > Purdue-pm at pm.org > http://mail.pm.org/mailman/listinfo/purdue-pm From westerman at purdue.edu Thu Aug 21 08:33:15 2014 From: westerman at purdue.edu (Rick Westerman) Date: Thu, 21 Aug 2014 11:33:15 -0400 (EDT) Subject: [Purdue-pm] Picking a programmer In-Reply-To: <53F60F41.6020703@purdue.edu> Message-ID: <295476976.52068.1408635195450.JavaMail.root@mailhub020.itcs.purdue.edu> ----- Original Message ----- > I think it's important that the person can communicate well. They need > to be able to work with other people to understand the content of the > programming task, the motivation, the impact, the users, etc. They > also > need to be able to document their code, if you want a really high > quality product. Communications would be my #1 criteria. Without the ability to communicate then you won't get good internal code comments nor external documentation. The daily status reports will basically be a grunt. The programmer will not listen to nor clarify customer comments, complaints and suggestions. All of those behaviors can be enforced however you won't get *good* results unless the programmer can actually communicate. > > > > On 8/21/14, 11:11 AM, derrick wrote: > > I'll throw out the ideas of: > > > > 1. problem solving > > 2. curiosity > > 3. creativity > > > > I'm interested in curiosity and creativity because requirements for > > projects are rarely well defined with first given. There ends up > > being > > a few revisions/clarifications as each side interprets them. Being > > able to figure out what people really want and tease out the use > > cases > > seems to be more of an art than a science. > > > > Understanding multiple programming paradigms (functional, > > procedural, > > object oriented, vector) is more interesting to me than knowing > > multiple languages. I feel that language is a lot about knowing the > > correct syntax, a little about understanding peculiarities between > > languages. Knowing how to think through a problem using a paradigm > > allows you to approach a problem from many angles, weighing the > > benefits of each. > > > > dsk > > > > > > On 08/20/2014 11:29 AM, Ken mcNamara wrote: > >> If you needed to hire a programmer for an important project... > >> > >> What do you look for? > >> > >> Multiple languages? > >> > >> System agnostic? > >> > >> Prefers programming to eating/sleeping? > >> > >> > >> What qualities make a good programmer? > >> > >> Any thoughts would be appreciated. > >> > >> KenMc > >> _______________________________________________ > >> Purdue-pm mailing list > >> Purdue-pm at pm.org > >> http://mail.pm.org/mailman/listinfo/purdue-pm > >> > > > > _______________________________________________ > > Purdue-pm mailing list > > Purdue-pm at pm.org > > http://mail.pm.org/mailman/listinfo/purdue-pm > > _______________________________________________ > Purdue-pm mailing list > Purdue-pm at pm.org > http://mail.pm.org/mailman/listinfo/purdue-pm -- Rick Westerman westerman at purdue.edu Bioinformatics specialist at the Genomics Facility. Phone: (765) 494-0505 FAX: (765) 496-7255 Department of Horticulture and Landscape Architecture 625 Agriculture Mall Drive West Lafayette, IN 47907-2010 Physically located in room S049, WSLR building From bradley.d.andersen at gmail.com Thu Aug 21 13:49:51 2014 From: bradley.d.andersen at gmail.com (Bradley Andersen) Date: Thu, 21 Aug 2014 16:49:51 -0400 Subject: [Purdue-pm] Picking a programmer In-Reply-To: <295476976.52068.1408635195450.JavaMail.root@mailhub020.itcs.purdue.edu> References: <53F60F41.6020703@purdue.edu> <295476976.52068.1408635195450.JavaMail.root@mailhub020.itcs.purdue.edu> Message-ID: +problem solving +cs knowledge specific language does not matter. /bda from yapc::eu in sunny bulgaria :) On Thu, Aug 21, 2014 at 11:33 AM, Rick Westerman wrote: > > > ----- Original Message ----- > > I think it's important that the person can communicate well. They need > > to be able to work with other people to understand the content of the > > programming task, the motivation, the impact, the users, etc. They > > also > > need to be able to document their code, if you want a really high > > quality product. > > Communications would be my #1 criteria. Without the ability to > communicate then you won't get good internal code comments nor external > documentation. The daily status reports will basically be a grunt. The > programmer will not listen to nor clarify customer comments, complaints and > suggestions. All of those behaviors can be enforced however you won't get > *good* results unless the programmer can actually communicate. > > > > > > > > > > > > On 8/21/14, 11:11 AM, derrick wrote: > > > I'll throw out the ideas of: > > > > > > 1. problem solving > > > 2. curiosity > > > 3. creativity > > > > > > I'm interested in curiosity and creativity because requirements for > > > projects are rarely well defined with first given. There ends up > > > being > > > a few revisions/clarifications as each side interprets them. Being > > > able to figure out what people really want and tease out the use > > > cases > > > seems to be more of an art than a science. > > > > > > Understanding multiple programming paradigms (functional, > > > procedural, > > > object oriented, vector) is more interesting to me than knowing > > > multiple languages. I feel that language is a lot about knowing the > > > correct syntax, a little about understanding peculiarities between > > > languages. Knowing how to think through a problem using a paradigm > > > allows you to approach a problem from many angles, weighing the > > > benefits of each. > > > > > > dsk > > > > > > > > > On 08/20/2014 11:29 AM, Ken mcNamara wrote: > > >> If you needed to hire a programmer for an important project... > > >> > > >> What do you look for? > > >> > > >> Multiple languages? > > >> > > >> System agnostic? > > >> > > >> Prefers programming to eating/sleeping? > > >> > > >> > > >> What qualities make a good programmer? > > >> > > >> Any thoughts would be appreciated. > > >> > > >> KenMc > > >> _______________________________________________ > > >> Purdue-pm mailing list > > >> Purdue-pm at pm.org > > >> http://mail.pm.org/mailman/listinfo/purdue-pm > > >> > > > > > > _______________________________________________ > > > Purdue-pm mailing list > > > Purdue-pm at pm.org > > > http://mail.pm.org/mailman/listinfo/purdue-pm > > > > _______________________________________________ > > Purdue-pm mailing list > > Purdue-pm at pm.org > > http://mail.pm.org/mailman/listinfo/purdue-pm > > -- > Rick Westerman > westerman at purdue.edu > > Bioinformatics specialist at the Genomics Facility. > Phone: (765) 494-0505 FAX: (765) 496-7255 > Department of Horticulture and Landscape Architecture > 625 Agriculture Mall Drive > West Lafayette, IN 47907-2010 > Physically located in room S049, WSLR building > _______________________________________________ > Purdue-pm mailing list > Purdue-pm at pm.org > http://mail.pm.org/mailman/listinfo/purdue-pm > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexmcn at tds.net Fri Aug 22 03:11:42 2014 From: alexmcn at tds.net (Ken mcNamara) Date: Fri, 22 Aug 2014 06:11:42 -0400 Subject: [Purdue-pm] Picking a programmer - summary Message-ID: Thanks for the answers - they were interesting and helpful. LANGUAGES - This statement from 'dsk' clarifies something I think is key - "Understanding multiple programming paradigms (functional, procedural, object oriented, vector) is more interesting to me than knowing multiple languages. I feel that language is a lot about knowing the correct syntax, a little about understanding peculiarities between languages. Knowing how to think through a problem using a paradigm allows you to approach a problem from many angles, weighing the benefits of each." My experience suggests that while most people (even technical people) can be taught to program - only a few will be able to do it well. This would explain why it's more important to hire an experienced (proven) programmer than it is to focus on "language experience". COMMUNICATION - Rick W., Mark Ward and dsk make points about communication dsk: "Being able to figure out what people really want and tease out the use cases seems to be more of an art than a science." Mark: " They need to be able to work with other people to understand the content of the programming task, the motivation, the impact, the users, etc. They also need to be able to document their code, if you want a really high quality product." Rick: "Without the ability to communicate then you won't get good internal code comments nor external documentation. The daily status reports will basically be a grunt. The programmer will not listen to nor clarify customer comments, complaints and suggestions. All of those behaviors can be enforced however you won't get *good* results unless the programmer can actually communicate." Perhaps this begins with the ability to accept criticism without taking it personally. It's hard to accept that your code (which you worked on for hours) could have a fatal flaw. SUBJECT MATTER - Mark Senn makes an important point - "Knows subject matter that project is for, at least well enough to get along if not actively understand it. " Speaks to the ability to communicate. The end user may not want to work with you if you have zero knowledge of their area. You don't have to be a 'subject matter expert' - but there has to be a starting point. The end user will educate a person who can communicate - but the programmer probably has to put forward the first effort. FUNDAMENTALS - Mark: " Organized. Experience. Detail oriented. Work ethic. Curiousity." dsk: "Problem Solving. Curiousity. Creativity." Bradley Westerman: "Problem Solving. CS knowledge." Without these - perhaps a person never even attempts programming? Thanks again. KenMc From markleightonfisher at gmail.com Fri Aug 22 04:33:04 2014 From: markleightonfisher at gmail.com (Mark Leighton Fisher) Date: Fri, 22 Aug 2014 07:33:04 -0400 Subject: [Purdue-pm] Picking a programmer - summary In-Reply-To: References: Message-ID: <53F72A70.6060507@gmail.com> I'll throw one more into the mix - checking that they can program rather than just cut'n'paste. I was lucky enough to start giving a little programming test when I helped with interviewing before I ran into a programmer who could talk his way around anything, but was unable to program his way out of a burning paper bag. The Fizz-Buzz problem is pretty good for this, as it doesn't require any domain-specific knowledge. -- ================= Mark Leighton Fisher markleightonfisher at gmail.com From mark at ecn.purdue.edu Fri Aug 22 05:41:08 2014 From: mark at ecn.purdue.edu (Mark Senn) Date: Fri, 22 Aug 2014 08:41:08 -0400 Subject: [Purdue-pm] Picking a programmer - summary In-Reply-To: References: Message-ID: <27541.1408711268@pier.ecn.purdue.edu> > Mark: " Organized. Experience. Detail oriented. Work ethic. Curiousity." > > dsk: "Problem Solving. Curiousity. Creativity." > > Bradley Westerman: "Problem Solving. CS knowledge." > Without these - perhaps a person never even attempts programming? Good point! Without patience, which is increasing difficult to find in undergraduate students at Purdue University, some people probably never get past writing their first hard programs that requires thinking, handling lots of special cases, learning new subject matter, etc. So, patience might be able to be added to the implicit qualities a programmer has. I'd like to add the two following qualities to my list. "Breaking a problem into component parts ignoring information that doesn't matter" makes programming easier. For example, in Mark went to McDonald's yesterday---it was hot and muggy---and took advantage of a deal to get two sandwiches for the price of one by filling out a survey at mcdvoice.com. He paid $5.16 for a $4.91 bill. How much money should he get get back from the young clerk? It's handy to minimize the number of coins one carries around. only paid $5.16 for a $4.91 bill. How much money should he get back? is relevant. The answer is 25 cents. "Being able to focus" is a key skill for a programmer. I think today's youth can't focus because school is becoming more group-oriented and they don't think as much on their own. I see students working together who can't go for more than a very minutes before drifting off into something unrelated. Their attention spans are near zero because they've never worked on a problem for more than a few minutes. They are constantly distracted by music, over the ear headphones (when crossing the street), Facebook, cell phones, etc. and I think that affects their brains (no references for that offhand but I've read that others think that also). Mark Senn, Systems Programmer, Engineering Computer Network, Purdue University From alexmcn at tds.net Sun Aug 24 03:03:40 2014 From: alexmcn at tds.net (Ken mcNamara) Date: Sun, 24 Aug 2014 06:03:40 -0400 Subject: [Purdue-pm] Picking a programmer - Summary 2 Message-ID: Mark F. and Mark S. contributed some additional valuable points - //////////////////////////////////// Thanks for the answers - they were interesting and helpful. LANGUAGES - This statement from 'dsk' clarifies something I think is key - "Understanding multiple programming paradigms (functional, procedural, object oriented, vector) is more interesting to me than knowing multiple languages. I feel that language is a lot about knowing the correct syntax, a little about understanding peculiarities between languages. Knowing how to think through a problem using a paradigm allows you to approach a problem from many angles, weighing the benefits of each." My experience suggests that while most people (even technical people) can be taught to program - only a few will be able to do it well. This would explain why it's more important to hire an experienced (proven) programmer than it is to focus on "language experience". COMMUNICATION - Rick W., Mark Ward and dsk make points about communication dsk: "Being able to figure out what people really want and tease out the use cases seems to be more of an art than a science." Mark: " They need to be able to work with other people to understand the content of the programming task, the motivation, the impact, the users, etc. They also need to be able to document their code, if you want a really high quality product." Rick: "Without the ability to communicate then you won't get good internal code comments nor external documentation. The daily status reports will basically be a grunt. The programmer will not listen to nor clarify customer comments, complaints and suggestions. All of those behaviors can be enforced however you won't get *good* results unless the programmer can actually communicate." Perhaps this begins with the ability to accept criticism without taking it personally. It's hard to accept that your code (which you worked on for hours) could have a fatal flaw. SUBJECT MATTER - Mark Senn makes an important point - "Knows subject matter that project is for, at least well enough to get along if not actively understand it. " Speaks to the ability to communicate. The end user may not want to work with you if you have zero knowledge of their area. You don't have to be a 'subject matter expert' - but there has to be a starting point. The end user will educate a person who can communicate - but the programmer probably has to put forward the first effort. TESTING - Mark Fisher adds a valuable point: I'll throw one more into the mix - checking that they can program rather than just cut'n'paste. I was lucky enough to start giving a little programming test when I helped with interviewing before I ran into a programmer who could talk his way around anything, but was unable to program his way out of a burning paper bag. The Fizz-Buzz problem is pretty good for this, as it doesn't require any domain-specific knowledge. FUNDAMENTALS (implicit qualities) - Mark: " Organized. Experience. Detail oriented. Work ethic. Curiousity." dsk: "Problem Solving. Curiousity. Creativity." Bradley Westerman: "Problem Solving. CS knowledge." Without these - perhaps a person never even attempts programming? Mark Senn added 3 points to fundamentals: Patience, Filtering out the noise, and Being able to Focus Without patience, which is increasing difficult to find in undergraduate students at Purdue University, some people probably never get past writing their first hard programs that requires thinking, handling lots of special cases, learning new subject matter, etc. So, patience might be able to be added to the implicit qualities a programmer has. "Breaking a problem into component parts ignoring information that doesn't matter" makes programming easier. For example, given this problem: " Mark went to McDonald's yesterday---it was hot and muggy---and took advantage of a deal to get two sandwiches for the price of one by filling out a survey at mcdvoice.com. He paid $5.16 for a $4.91 bill. How much money should he get get back from the young clerk? It's handy to minimize the number of coins one carries around." The only thing that is relevant is: "?.paid $5.16 for a $4.91 bill. How much money should he get back?'?." The answer is 25 cents. One more subtle point here - the client might reject the program because it should have returned "A quarter". Speaks to the point of taking criticism. Finally - FOCUS "Being able to focus" is a key skill for a programmer. I think today's youth can't focus because school is becoming more group-oriented and they don't think as much on their own. I see students working together who can't go for more than a very minutes before drifting off into something unrelated. Their attention spans are near zero because they've never worked on a problem for more than a few minutes. They are constantly distracted by music, over the ear headphones (when crossing the street), Facebook, cell phones, etc. and I think that affects their brains (no references for that offhand but I've read that others think that also). Thank you all! KenMc -------------- next part -------------- An HTML attachment was scrubbed... URL: From derrick at csociety.org Sun Aug 24 10:04:36 2014 From: derrick at csociety.org (derrick) Date: Sun, 24 Aug 2014 13:04:36 -0400 Subject: [Purdue-pm] yelp dataset challenge Message-ID: <53FA1B24.3010606@csociety.org> Yelp is hosting a dataset challenge. I don't think I'll have time to do anything serious right now, but I am interested in learning machine learning techniques. If you are doing anything with this or wants to, let me know. http://engineeringblog.yelp.com/2014/08/the-yelp-dataset-challenge-goes-international-new-data-new-cities-open-to-students-worldwide.html dsk