This seems great. In the past I had set up Flickr to at least email all my daughter's grandparents so they could see new photos of her. As Flickr is dying and this case doesn't seem well handled by Instagram/Google Photos this seems like a really nice way to share family photos with everyone.
I'd never heard of Donor Advised Funds before. I'd be curious if others have had a similar good (or bad) experience. I'm thinking I might do it for 2017 and wondering if there are any other things to be aware of.
For a side project I've deployed some simple endpoints to Heroku and used Spark (http://sparkjava.com/). Spark is a Java Sinatra clone rather than full Rails.
That said, not sure I'd pick it for simple side-projects. Part of the benefit here is how it works for a large dev team, with a large codebase, etc.
I work at HubSpot, and was among the initially skeptical from having had bad experiences in Java in the distant past and spent more time in Ruby in the years prior which I mostly enjoyed.
The Java ecosystem truly saved itself from its own enterprise madness. Libraries and frameworks today look nothing like they did in the past. I think that is somewhat due to language features (annotations, lambdas, etc) but also due to a cultural shift in what is valued.
One of the things I've appreciated more than I would have expected is by having a single back-end language we have very strong community of developers. There is no split among different factions. (I hear rumors of sharp divides between python and node camps at Uber, for example.) Even though technically we have a platform capable of running languages in many languages, the value of the community focused on a single back-end language toolchain is extremely valuable.
This right here. I have been preaching this message for ages. You simply cannot account the immense benefits of having everyone working on the same stack. Even just splitting into two languages you start getting huge knowledge barriers and a major loss in shared skill growth. If you've chosen Java/C#/etc for your base language you need to have a DAMNED good reason for bringing in another one. And the other one being the best option for the problem of the day is not a good enough reason if your primary language is capable of solving the same problem in a slightly less elegant way.
Yep. I've used a variety of different languages, and it always struck me as odd that Java was considered some uncool cumbersome language, and enterprise-y in some sort of bad way. It's not a dream to code in, but it is highly practical and in no way limits what you can do or makes anything particularly hard. I see now that I joined the Java party in better days.
I've done a lot of Java, and I'd say the stereotypes didn't come from nowhere (XML is great! Enjoy using XML for dependency injection and configuration!). Not to mention the lack of expressivity of the language causing the proliferation of FactoryBeans.
The other issue is that the "IE effect": the language stopped evolving for years. In the meantime, Microsoft launched C#, and Java is only catching up now in terms of convenience. But even with Java 8, as far as I know, a lot of things are still strictly worse than in many other languages (no import aliases in 2016, no shorthand for getters/setters...). To a large extent, it's still a language that forces you to live in a IDE even for trivial things, due to the amount of boilerplate you need for even simple things.
Of course, compared to C#, it still benefits from a considerably larger and IMHO higher-quality ecosystem, as well as working very well with some non-Java open-source solutions (eg, Postgres), though it's generally poorly integrated on all platforms it runs on.
C# the language is fine, but C# the ecosystem is kind of a mess. There are multiple approaches that attempt to solve the same problem (PCLs versus shared libraries; both have their place but they overlap uncomfortably) and cross-platform development is an abject disaster (CoreCLR may eventually get to a good place but I wouldn't use Mono in production for long-running services). NuGet--itself a problem in many ways, it's very poor the second you get off the happy path--exists but in my experience its usage is spotty, whereas even the jankiest Ant projects I've ever worked with at least used Ivy. Libraries in NuGet are also, I think, a lot more hit-or-miss than I'm used to either in Ruby or on the JVM. Some stuff is real good (JSON.NET!). Some stuff is real, real bad (the bajillion competing and differently defective YAML tools), and there isn't the same sort of cultural focus on pushing the good to the forefront.
This isn't a strong defense of Java, because I think the JVM and its ecosystem isn't super great either. I really like C# and I pay for ReSharper despite not doing C# professionally (I've been using it for about a decade but never taken a job in it). But while C#-the-language has greatly improved, the ecosystem still feels five-plus years behind.
That's why I think Kotlin is going to clean up. It's a language specifically designed to be commercially successful by providing you with a better Java. For instance this line of code:
data class Person(var name: String, val age: Int)
compiles down to a JavaBean with getName/setName type methods, a getAge but no setAge (val is immutable), an equals, a hashCode, a toString and a few other useful methods as well like copy() which lets you create clones of the object with any fields modified.
So with Kotlin you get many of the benefits of C# and some features that C# is only just introducing now, or in its next versions, but it all interops seamlessly with Java.
I think it will fail in the same way as Xtend or (to a certain extent) perl. It puts too much focus on one-off productivity features which results in an inconsistent language with loads of edge cases, and it doesn't have any compelling "you can't do this in Java" selling points, just a bunch of minor syntax sugar.
Ceylon has all the advantages of Kotlin, but put together a lot more coherently, and with a really compelling fundamental feature (union types).
Last time I used it was when EJB, JSP and co. were "big". And it always felt like a struggle to get this strange overload of "design patterns" running. Maven and code generators did their fair share to add some "what is even happening"-moments to my experiences.
I just sticked to get things up and running fast with JavaScript and throw in some C if the performance suffers too much.
my last exposure to Java was many years ago in the EJBs timeframe, and I didn't have a lot of fun with it (leading to staying away from Java positions since then).
Last year I had to work on a Spark application and I was honestly a bit uneasy when I started but I was quite surprised at how much nicer it was to develop in Java 8 and how well IntelliJ worked (first time in probably 20 years that I wasn't using emacs for development) and the performance was quite surprising as well.
I still mostly work in python day-to-day, but if I was looking at starting something from scratch, Java would definitely something I'd look at quite seriously.
The post mentions a few: Dropwizard for RESTful APIs (http://www.dropwizard.io which includes a bunch of good libraries), Guava, Guice, Hysterix, etc. We use Kafka for stream processing, Hadoop for batch processing.
SQL is just one type of DB language we use, but yes we use JDBI with some extensions we've built (such as https://github.com/HubSpot/Rosetta and other non-opensource) for our SQL database of choice, MySQL.
But we also use a number of other databases with native java clients, such as HBase and ElasticSearch.
Parallel Universe made a comprehensive 3-part blog post to modern Java. They cover language features like lambdas, as well as notable libraries for build, deployment, monitoring, and web development.
So, is the idea to avoid ORM, JSF, JavaBeans, CDI Beans and all JavaEE in general?
How is web application development done? I guess the back-end is made in Java with an API, and another language is used for the front-end.
HubSpot | Cambridge/Boston/Dublin | full time, onsite
Looking for front-end (React/Flux, Backbone, ES6/CoffeeScript) and back-end (Java8, HBase, Kafka, Hadoop/Spark, ElasticSearch) developers who enjoy working in small teams that own significant parts of our products. Developer autonomy and responsibility are what fuels our product culture. Our products are helping transform how small businesses do marketing & sales so they grow while delighting their customers.
HubSpot | Cambridge/Boston/Dublin | full time, onsite
Looking for front-end (React/Flux, Backbone, ES6/CoffeeScript) and back-end (Java8, HBase, Kafka, Hadoop/Spark, ElasticSearch) developers who enjoy working in small teams that own significant parts of our products. Developer autonomy and responsibility are what fuels our product culture. Our products are helping transform how small businesses do marketing & sales so they grow while delighting their customers.
The products we build help small businesses grow. More on our product team and roles on our site: http://product.hubspot.com/ and our company culture: http://culturecode.com
Or ping me (champion at hubspot) with any questions.
HubSpot | Cambridge/Boston/Dublin | full time, onsite
Looking for front-end (React/Flux, Backbone, ES6/CoffeeScript) and back-end (Java8, HBase, Kafka, Hadoop/Spark, ElasticSearch) developers who enjoy working in small teams that own significant parts of our products. Developer autonomy and responsibility are what fuels our product culture. Our products are helping transform how small businesses do marketing & sales so they grow while delighting their customers.
