Re: instrument code only in dev, with lein

[Brian Craft]

So, this seems to work pretty easily, though I'm relying on 'require' 
resolving references in the same order as the directories in :source-paths. 
For :source-paths ["src-dev", "src"], it will find 
src-dev/foo/instrument.clj,instead of src/foo/instrument.clj, when both 
exist.

I can't find anything in the lein or clojure docs that specifies this 
behavior. Is this a safe assumption?

On Friday, March 17, 2017 at 5:24:30 PM UTC-7, Matching Socks wrote:
>
> In a nutshell: leverage distinct classpaths.  Adjust the :dev profile in 
> project.clj to prepend a directory other than src to :source-paths, and 
> likewise a directory other than resources for :resource-paths.  In 
> development, use code or resources from the dev classpath to override 
> default behaviors on the uberjarred classpath.  See the sample Lein 
> project.clj:
>
> https://github.com/technomancy/leiningen/blob/master/sample.project.clj
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure resume tips?

[James Gatannah]

To get back on-target, I think you should highlight 1 or maybe 2 of your 
github repos and go flesh them out.

I had high hopes for both click-time-fun and cljs-game, but wasn't sure 
what to try or where to start. Working demos are pretty magical, and, 
honestly, incredibly rare.

https://github.com/noffle/art-of-readme has some advice that I've been 
planning to take to heart for a while now about how to help other people 
understand what your projects are about.

That probably won't help your resume get through the original HR screen, 
but it can definitely make interviewers stand up and take notice.

Good luck,
James


On Thursday, March 23, 2017 at 12:10:30 PM UTC-5, Jason Basanese wrote:
>
> Attached is a fairly bad resume that I am using. Any tips on how I might 
> change it to appeal to more places that are looking for functional 
> developers?
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure resume tips?

[James Gatannah]

On Thursday, March 23, 2017 at 2:00:28 PM UTC-5, puzzler wrote:
>
> On Thu, Mar 23, 2017 at 11:24 AM, Luke Burton  > wrote:
>
 

> Insightful post about a lot of things related to hiring, but I have to 
> take exception with this very last point.  Recently, a friend of mine 
> sought out a data science position in the Seattle area.  Each prospective 
> employer gave him a take-home assignment that required 30-40 work hours to 
> complete.  Some of the assignments were real problems the company was 
> facing, so he was effectively being asked to do free consulting work for 
> each company.  This is a horrible, burdensome interview practice and it 
> would be dreadful if it became the norm in the software industry. 
> Suggesting that someone offer to do a take-home project may make sense in 
> specific cases for an inexperienced candidate, but I fear it starts our 
> industry down the slippery slope.
>

It's not quite on-topic, since this is a post-resume story.

But once upon a time I worked at a company where a fairly senior candidate 
was asked about whatever real-world problem the interviewer was working on 
at the time. I think it was a relaxed "So, how would you approach this 
particular scenario?" big-picture kind of question.

We didn't hire him.

He sent us a bill for an hour of consulting.

The legal department told us to pay it and never, ever, under any 
circumstances, ask any question that could be remotely construed as 
relevant to our actual business needs.

Personally, I enjoy the little "Spend a couple of hours knocking this out" 
challenges, as long as I don't get graded on criteria that wasn't mentioned 
up front ("Our internal style guide, which you've never seen, dictates that 
you must do X"). But I'm at the point where I'd rather point people to 
github so we can talk about real projects that actually have serious 
time/thought investments.

And, on the flip side, I'd rather look at what a candidate's done there, 
even if it does take more time/effort on the hiring side than seeing how 
they approach a cookie-cutter project.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: livecoding with Quil middleware

[Jay Porcasi]

thank you very much Nikita
by playing with anonymous functions vs partial applications i got exactly 
the behaviour i was after!
that's awesome :-)
Jay

On Friday, March 24, 2017 at 7:00:41 AM UTC+7, Nikita Beloglazov wrote:
>
> Yes, middleware runs exactly once so you can't redefine it. In the example 
> with fill-background you can redefine fill-backgfound:
>
>  (def fill-background [draw-fn] (draw-fn))
>
> Which essentially makes it identify. So that's would be my recommendation: 
> put all logic to fill-background and let fill-background-middleware be 
> just a wrapper like it is now. 
>
> On Wednesday, March 22, 2017 at 8:22:59 PM UTC-7, Jay Porcasi wrote:
>>
>> hi Nikita
>>
>> thank you so much for your explanation, it's very clear (and a bit 
>> surprising to learn that partial and anonymous functions have a slightly 
>> different semantics)
>>
>> i am able to get the live coding behaviour when i redefine 
>> fill-background (as per your example, and that's great that it is 
>> possible)
>>
>> however it seems not possible to get a live coding behaviour when 
>> redefining fill-background-middleware (the middleware function itself)
>>
>> for example i would love if i could evaluate:
>> (def fill-background-middleware identity)
>> and see the background reverting to what it was before (that's just an 
>> example)
>>
>> but this seems not possible because that middleware runs just once, when 
>> the sketch is initialized
>>
>> do i understand correctly?
>> and is it something that would not be achievable by any other means? (one 
>> more level of indirection perhaps? :-)
>>
>> Jay
>>
>>
>>
>> On Monday, March 20, 2017 at 11:09:35 AM UTC+7, Nikita Beloglazov wrote:
>>>
>>> Hi Jay
>>>
>>> Yes, draw and update functions support live coding out-of-box. It's 
>>> trickier with middleware. The main thing is that middleware run once, when 
>>> initializing sketch. The goal of middleware is to take user provided 
>>> settings (like draw and update funcitons), optionally wrap some of them in 
>>> another functions and return new settings. It depends on your middleware 
>>> implementation whether it supports live coding. As a simple example let's 
>>> say you have a simple middleware that fills background with some color 
>>> before each draw. Here is how you can do it so it supports live reloading:
>>>
>>> (defn fill-background [draw-fn]
>>>   (q/background 255)
>>>   (draw-fn))
>>>
>>> (defn fill-background-middleware [options]
>>>   (let [user-draw (:draw options)]
>>> (assoc options
>>>   :draw #(fill-background user-draw
>>>
>>> (q/defsketch abc
>>>   :draw ...
>>>   :middleware [fill-background-middleware])
>>>
>>> If you try changing 'fill-background', for example change color from 255 
>>> to 200, then you should see effect immediately. The trick is on line 
>>>
>>> :draw #(fill-background user-draw
>>>
>>> Here we say that new draw function is an anonymous function that calls 
>>> fill-background. So on each draw invocation it will lookup fill-background 
>>> function by name. If you reload this function - name will stay the same, 
>>> but implementation changes and interpreter pick ups new function. On the 
>>> other hand if you do following:
>>>
>>> :draw (partial fill-background user-draw)
>>>
>>> Then you won't get live reloading. Even though these 2 approaches 
>>> essentially do the same, the second approach actually "remembers" original 
>>> version of fill-background. If you try changing that function it won't have 
>>> effect as interpreter no longer looks up function by name. 
>>>
>>> I'm probably not explaining it very well but I hope it's still helpful. 
>>> If you still have problems with your middleware - feel free to post the 
>>> code in this thread and I'll take a look.
>>>
>>> Nikita
>>>
>>> On Friday, March 17, 2017 at 7:50:02 PM UTC-7, Jay Porcasi wrote:

 hello, i hope this is the place to discuss questions about Quil (i 
 couldn't find a dedicated forum)

 and first of all, kudos to Nikita for this incredible library, which i 
 find even better than the original Processing
 it's not just a matter of using a different syntax than java, but 
 Nikita actually created something more powerful and flexible than 
 Processing

 i'm particularly fond of the middleware functionality, which is a 
 stroke of genius: so simple in retrospect and so powerful, opening a whole 
 new way of possibilities of structuring one's own work in a modular fashion

 so i have one question regarding live coding and middleware

 if i redefine a function that i associate to :setup, :update or :draw 
 keys, i can see my running sketch changing on the fly, reflecting the new 
 definitions

 this is not the case however if i redefine a function that i use as a 
 middleware

 is it an intrinsic limitation? would it be possible to extend the live 
 coding behaviour to middlewares as well?

 tha

Re: off-topic: stackof developer survey

[Mars0i]

On Thursday, March 23, 2017 at 7:49:40 PM UTC-5, Mars0i wrote:
>
> The highest-paid win suggests there's greater demand than supply, so 
> people who aren't comfortable with FP or lisp may be forced to code in 
> Clojure, or try to for the sake of a job without doing it right, and are 
> unhappy as a result.


There are better explanations in the #off-topic channel of the Clojurians 
group in slack. 

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: off-topic: stackof developer survey

[Mars0i]

The highest-paid win suggests there's greater demand than supply, so people who 
aren't comfortable with FP or lisp may be forced to code in Clojure, or try to 
for the sake of a job without doing it right, and are unhappy as a result.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

pager for lein repl?

[Joe Python]

Is there a equivalent of less/more like pager (found in Linux shells) for 
Leiningen repl?
 
The lein repl is fast enough for me displaying large data structures making 
it great for exploratory programming. But it is desperately missing a pager.

- Joe

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Can you extend a Java class, and add new fields and constructors to it?

[Mars0i]

gen-class lets you define multiple constructors: 
http://stackoverflow.com/questions/18780071/clojure-multiple-constructors-using-gen-class

You can't define multiple fields that can be directed accessed from Java, but 
you can define accessors for data you store in other ways.  gen-class gives you 
only a single variable that's specific to each instance of the class, but you 
can e.g. put a map in it, with atoms as values if you need mutability, and 
define the accessors to access those.

(If you have a lot of variables that you're handling that way, you may want to 
write a gen-class-generating macro.  That's what I did, but it's not general; 
it's tailored to my application.)

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: livecoding with Quil middleware

[Nikita Beloglazov]

Yes, middleware runs exactly once so you can't redefine it. In the example 
with fill-background you can redefine fill-backgfound:

 (def fill-background [draw-fn] (draw-fn))

Which essentially makes it identify. So that's would be my recommendation: 
put all logic to fill-background and let fill-background-middleware be just 
a wrapper like it is now. 

On Wednesday, March 22, 2017 at 8:22:59 PM UTC-7, Jay Porcasi wrote:
>
> hi Nikita
>
> thank you so much for your explanation, it's very clear (and a bit 
> surprising to learn that partial and anonymous functions have a slightly 
> different semantics)
>
> i am able to get the live coding behaviour when i redefine fill-background 
> (as 
> per your example, and that's great that it is possible)
>
> however it seems not possible to get a live coding behaviour when 
> redefining fill-background-middleware (the middleware function itself)
>
> for example i would love if i could evaluate:
> (def fill-background-middleware identity)
> and see the background reverting to what it was before (that's just an 
> example)
>
> but this seems not possible because that middleware runs just once, when 
> the sketch is initialized
>
> do i understand correctly?
> and is it something that would not be achievable by any other means? (one 
> more level of indirection perhaps? :-)
>
> Jay
>
>
>
> On Monday, March 20, 2017 at 11:09:35 AM UTC+7, Nikita Beloglazov wrote:
>>
>> Hi Jay
>>
>> Yes, draw and update functions support live coding out-of-box. It's 
>> trickier with middleware. The main thing is that middleware run once, when 
>> initializing sketch. The goal of middleware is to take user provided 
>> settings (like draw and update funcitons), optionally wrap some of them in 
>> another functions and return new settings. It depends on your middleware 
>> implementation whether it supports live coding. As a simple example let's 
>> say you have a simple middleware that fills background with some color 
>> before each draw. Here is how you can do it so it supports live reloading:
>>
>> (defn fill-background [draw-fn]
>>   (q/background 255)
>>   (draw-fn))
>>
>> (defn fill-background-middleware [options]
>>   (let [user-draw (:draw options)]
>> (assoc options
>>   :draw #(fill-background user-draw
>>
>> (q/defsketch abc
>>   :draw ...
>>   :middleware [fill-background-middleware])
>>
>> If you try changing 'fill-background', for example change color from 255 
>> to 200, then you should see effect immediately. The trick is on line 
>>
>> :draw #(fill-background user-draw
>>
>> Here we say that new draw function is an anonymous function that calls 
>> fill-background. So on each draw invocation it will lookup fill-background 
>> function by name. If you reload this function - name will stay the same, 
>> but implementation changes and interpreter pick ups new function. On the 
>> other hand if you do following:
>>
>> :draw (partial fill-background user-draw)
>>
>> Then you won't get live reloading. Even though these 2 approaches 
>> essentially do the same, the second approach actually "remembers" original 
>> version of fill-background. If you try changing that function it won't have 
>> effect as interpreter no longer looks up function by name. 
>>
>> I'm probably not explaining it very well but I hope it's still helpful. 
>> If you still have problems with your middleware - feel free to post the 
>> code in this thread and I'll take a look.
>>
>> Nikita
>>
>> On Friday, March 17, 2017 at 7:50:02 PM UTC-7, Jay Porcasi wrote:
>>>
>>> hello, i hope this is the place to discuss questions about Quil (i 
>>> couldn't find a dedicated forum)
>>>
>>> and first of all, kudos to Nikita for this incredible library, which i 
>>> find even better than the original Processing
>>> it's not just a matter of using a different syntax than java, but Nikita 
>>> actually created something more powerful and flexible than Processing
>>>
>>> i'm particularly fond of the middleware functionality, which is a stroke 
>>> of genius: so simple in retrospect and so powerful, opening a whole new way 
>>> of possibilities of structuring one's own work in a modular fashion
>>>
>>> so i have one question regarding live coding and middleware
>>>
>>> if i redefine a function that i associate to :setup, :update or :draw 
>>> keys, i can see my running sketch changing on the fly, reflecting the new 
>>> definitions
>>>
>>> this is not the case however if i redefine a function that i use as a 
>>> middleware
>>>
>>> is it an intrinsic limitation? would it be possible to extend the live 
>>> coding behaviour to middlewares as well?
>>>
>>> thanks and long live Quil,
>>> Jay
>>>
>>>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@goo

Re: Clojure resume tips?

[Luke Burton]

> On Mar 23, 2017, at 11:59 AM, Mark Engelberg  wrote:
> 
> On Thu, Mar 23, 2017 at 11:24 AM, Luke Burton  > wrote:
> 
> * So … if I was in your position, knowing what I know now, if I couldn't find 
> companies that had very progressive hiring practices, I would make my resume 
> stand out by leading in with an offer to spend a few hours writing a small 
> implementation of anything the hiring manager would like me to write. Many 
> hiring mangers are scared by take home projects because they're afraid of 
> what the best candidate will think. "It's an insult to experienced 
> candidates!" or "how would a rockstar candidate possibly spare the time?" But 
> secretly I think all hiring mangers *really* want to know what it will be 
> like to have you write code on their behalf. It's just not the industry norm 
> to ask.
> 
> Insightful post about a lot of things related to hiring, but I have to take 
> exception with this very last point.  Recently, a friend of mine sought out a 
> data science position in the Seattle area.  Each prospective employer gave 
> him a take-home assignment that required 30-40 work hours to complete.  Some 
> of the assignments were real problems the company was facing, so he was 
> effectively being asked to do free consulting work for each company.  This is 
> a horrible, burdensome interview practice and it would be dreadful if it 
> became the norm in the software industry. Suggesting that someone offer to do 
> a take-home project may make sense in specific cases for an inexperienced 
> candidate, but I fear it starts our industry down the slippery slope.

I definitely share the concern. 30-40 hours is totally not what I'd consider a 
take home project. I also think "real problems facing the company" has a host 
of issues associated with it, including the one you pointed out which is that 
it blurs the line between free labor and hiring pipeline. While I believe that 
a hiring pipeline this onerous is very unlikely to catch on and be the industry 
norm, I would put forward the proposal that a take-home project must *not* be 
work that directly contributes to the hiring company's value stream. 

I'd like to give you a sense of how I approached this problem, just to give a 
counterexample that is maybe more hopeful:

* We encouraged the candidate to have fun with the problem! The goal was not to 
stress them out under a deadline, but to give them enough time to relax into 
their normal engineering mindset. They could use any resource they liked, any 
framework or language they felt would suit the solution.

* They got to pick their own starting date, and deliver us a self-contained 
artifact of some kind a week later. Having to write "hand off" instructions was 
surprisingly telling! It was also surprising to see a candidate's git repo, to 
see how their solution evolved over time.

* The project was very, very general in specification. Almost uncomfortably 
open ended. I value candidates that can work with loose specifications, but I 
also wanted to let the candidate decide what they felt was "done" enough to 
share. And I wanted to ensure it wasn't possible to find canned solutions on 
the internet (Facebook found that their iOS candidates became increasingly 
adept at writing exactly the same tic-tac-toe interfaces, hmm …) 

* Their project solution would be the primary focus of any in-person interviews 
we followed up with. This is no small point, it really gave those interviews a 
sense of structure and purpose that I had not seen before. The candidate's 
memory for their code is fresh and they feel confident, while the interviewers 
all had plenty of good questions having checked out the candidate's repo and 
deep dived into it.

There was other minutiae specific to the role and company that isn't 
interesting here, but hopefully that gives some sense of how I tried to balance 
the various concerns. I think it parallelizes nicely too, in the future I would 
not hesitate to send a project like this out to *everyone* who submitted a 
resume, just to see what comes back. 

I guess I've spilled this many words I may as well share what the project was. 
Aside from lots of preamble explaining the above, what I sent out was:

> The city of San Francisco has an open data repository located at 
> data.sfgov.org . The amount of available data is 
> pretty impressive. Your task is to create a composite metric for city 
> restaurants, based on at least two variables from data in the repository. It 
> need not take itself too seriously, if you want to rate a location based on 
> its seismic activity and wind speed, go for it. It could be qualitative or 
> quantitative. 
> 
> The end result should be a full stack web application that gives us the 
> ability to browse or search your calculated results. We'd like to see what 
> you can do in a week. Keep it simple! A working, but simple result is more 
> impressive than a complicated, 

Re: Clojure resume tips?

[Mark Engelberg]

On Thu, Mar 23, 2017 at 11:24 AM, Luke Burton  wrote:

>
> * So … if I was in your position, knowing what I know now, if I couldn't
> find companies that had very progressive hiring practices, I would make my
> resume stand out by leading in with an offer to spend a few hours writing a
> small implementation of anything the hiring manager would like me to write.
> Many hiring mangers are scared by take home projects because they're afraid
> of what the best candidate will think. "It's an insult to experienced
> candidates!" or "how would a rockstar candidate possibly spare the time?"
> But secretly I think all hiring mangers *really* want to know what it will
> be like to have you write code on their behalf. It's just not the industry
> norm to ask.
>

Insightful post about a lot of things related to hiring, but I have to take
exception with this very last point.  Recently, a friend of mine sought out
a data science position in the Seattle area.  Each prospective employer
gave him a take-home assignment that required 30-40 work hours to
complete.  Some of the assignments were real problems the company was
facing, so he was effectively being asked to do free consulting work for
each company.  This is a horrible, burdensome interview practice and it
would be dreadful if it became the norm in the software industry.
Suggesting that someone offer to do a take-home project may make sense in
specific cases for an inexperienced candidate, but I fear it starts our
industry down the slippery slope.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure resume tips?

[Luke Burton]

> On Mar 23, 2017, at 10:10 AM, Jason Basanese  wrote:
> 
> Attached is a fairly bad resume that I am using. Any tips on how I might 
> change it to appeal to more places that are looking for functional developers?

Couple of general tips … based on a few decades of looking at these things :) 
Sorry about the length but I care a lot about hiring!

* Redact your home address and phone number when you circulate it on the open 
internet. I wouldn't even include that in a resume I sent to an organization, 
personally.

* Resumes are the worst. There's almost no correlation between "things the 
candidate had on his/her resume" and "that candidate is performing really well 
for us 2 years later", but we persist in using them because everything else is 
a lot more work. Just keep that in mind before you think there's something 
"wrong" with your resume.

* Resumes should be considered a marketing document. A classic new grad mistake 
is to think that what hiring mangers and recruiters are looking for is a 
complete transcript and accurate information. What they're actually looking for 
is purely subjective. I could tell you stories - resumes skipped over for the 
dumbest of reasons. After looking through hundreds, people start cutting 
corners or just plain discriminating. So, think of it as serving roughly the 
same purpose as a blurb on the back of a paperback novel.

* To play along with the resume game, I recommend customizing your resume to 
the greatest extent possible based on what you know about the job. That's "the 
job" singular, as in you need to do this for each application. It's easy to 
carpet bomb the same resume across many companies, but you simply won't stand 
out. You are on the right track here already - what would make it appealing to 
places looking for functional developers? Take it a step further and find those 
places, then write something that specifically targets them. Remember it's not 
just about keywords, you also have to come across as someone who might fit the 
culture.

* To avoid (or supplement) playing the resume game, build relationships. Keep 
all your projects up on GitHub, find and cultivate 
 things you want to stick at and 
improve, and start getting to know people. Meetups, fixing issues on other 
people's projects, it doesn't have to be super involved, it just has to be an 
involvement. The absolute best jobs you will ever land will come from people 
who know the quality of your work and recommend you from the inside. 

* I am a huge fan of Thomas Ptacek's perspective on hiring 
. Very much worth your 
time to read. If you can find a company that asks candidates to write some code 
- actual code like you'll be writing on the job, not a graph traversal puzzle - 
then jump on that chance. I started applying these techniques and we 
immediately experienced an inversion between who we thought looked strong on 
paper and who ended up being a great engineering fit for our team. This 
candidate we hired would have flunked the keyword filter had we used one, they 
had not used a single technology in common use for our team. Eye opening. 

* So … if I was in your position, knowing what I know now, if I couldn't find 
companies that had very progressive hiring practices, I would make my resume 
stand out by leading in with an offer to spend a few hours writing a small 
implementation of anything the hiring manager would like me to write. Many 
hiring mangers are scared by take home projects because they're afraid of what 
the best candidate will think. "It's an insult to experienced candidates!" or 
"how would a rockstar candidate possibly spare the time?" But secretly I think 
all hiring mangers *really* want to know what it will be like to have you write 
code on their behalf. It's just not the industry norm to ask.

Hope this helps! Good luck …

Luke.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure resume tips?

[Moe Aboulkheir]

Jason,

If it were my resumé, I would consider including only the technologies I
had interest in working with professionally.  Getting involved in
collaborative open source development (i.e. contributing to established
projects) is likely to increase your confidence, as well as that of a
prospective employer - you could consider shunting off the coursework
details (or listing those as "Interests", if they're interests) if you had
some voluntary development to put in its place.  Other ways to fill out
space while improving content would be to include a generic (i.e. not
job-specific) introduction beneath the heading, or using complete sentences
for the job description at the bottom.  If you go with bullet points, using
a list indicator might make this clearer.

As far as visual feedback: it might scan better if the section headings in
the left column were kept to single words (i.e. no line breaks), and were
vertically justified with the top of corresponding piece of text in the
adjacent column (using a table with invisible borders).  The alignment of
the info icons (which are a good call) is off in a similar way, and that
block does not appear horizontally centred to me.  Some colour variation
may help also - examples would be converting the urls into links (with the
url as the link text, for printing), or using a dark shade of grey for
heading or title text.

Take care,
Moe

On Thu, Mar 23, 2017 at 5:10 PM, Jason Basanese 
wrote:

> Attached is a fairly bad resume that I am using. Any tips on how I might
> change it to appeal to more places that are looking for functional
> developers?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ANN] Lacinia 0.13.0

[Howard Lewis Ship]

Lacinia is an open-source implementation of Facebook's GraphQL
specification, in Clojure.

GraphQL is an outstanding approach to getting diverse clients and servers
exchanging data cleanly and efficiently.

This is our formal release announcement:
https://medium.com/walmartlabs/open-sourcing-lacinia-our-graphql-library-for-clojure-96a4ce5fc7b8#.ypdrfypzq

The GitHub repository is https://github.com/walmartlabs/lacinia

This is the first public release of Lacinia.

I'll be discussing GraphQL and Lacinia next week at Clojure/West:
http://2017.clojurewest.org/clojure-graphql/

-- 
Howard M. Lewis Ship

Senior Mobile Developer at Walmart Labs

Creator of Apache Tapestry

(971) 678-5210
http://howardlewisship.com
@hlship

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure resume tips?

[Gary Trakhman]

I'd put examples of interesting (hard, nontrivial) projects you worked on
during your time, not just keywords.  The function of the resume is to
motivate someone to look deeper instead of throwing it out.  The function
of the top of the resume is to hook someone to read the rest of it.  What's
special about you?  You can pack a lot into a single page, I think yours
has a lot of whitespace.  Does your school have a resume workshop or
something like that?

On Thu, Mar 23, 2017 at 1:10 PM Jason Basanese 
wrote:

> Attached is a fairly bad resume that I am using. Any tips on how I might
> change it to appeal to more places that are looking for functional
> developers?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Core-async transducers with atoms

[Elena Canovi]

I have a question about transducers in core.async channels.

As far as I understand, if I define a channel with a transducer, the latter 
cannot depend on any other external argument other than what is put on the 
former.
So the transducer works in a purely functional fashion. 

Here is the question: is it idiomatic to define a transducer which depends 
(without side-effects) on a globally defined atom? 

Consider this example with a chatroom. Suppose we have a set (called 
banned-users) containing the names of users who have been banned from the 
chat. Let us initialize banned-users like this: 

(def banned-users (atom #{}))

Let us further suppose that this set can change in time with users added 
and removed asynchronously.
Every user can send messages to the server containing their name and the 
actual text of the message, in this format:

{:name "John" :text "Hi, friends!"}

Depending on whether the user is banned or not, the server will broadcast 
their message to all the other users or not. To this aim, let us define a 
channel with a transducer:

(def server (chan 1 (filter #(not (contains? @banned-users (:name  %) ) )))

As you can see, the effect of the transducer on the input message depends 
on the current value of banned-users. In other words, the channel does not 
work in a purely functional way, because given an input message, the result 
of applying the transducer will depend on the global context.

Is this idiomatic or do you suggest other solutions? Thanks!
​

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

How do I spec a nullary function?

[Alex Miller]

(s/fdef :args (s/cat) ...

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

How do I spec a nullary function?

[Didier]

I'm trying to fdef a function of no arguments, how would I go about it? I 
only want a spec for the return value basically?

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.