202 karma · joined August 16, 2007
We are a healthcare company working with AI in non-patient facing tasks. Looking for a US-based UI engineer to work on a per-project basis in collaboration with our design and product teams to build out our React app based on Figma designs.
==[Tasks and Deliverables]==
Develop a frontend UI based on Figma designs using React and Next.js.
Implement pre-built UI component libraries to ensure efficiency and consistency.
Translate the Figma designs into a proper design system in CSS.
Ensure seamless integration with backend APIs.
Collaborate with designers and backend engineers to optimize user experience.
Set up project structure, formatting, and best practices for scalable development.
==[Required Experience]==
Strong proficiency in React and Next.js.
Experience translating Figma designs into functional UIs.
Familiarity with component-based UI frameworks (e.g., Mantine, DaisyUI, Tailwind).
Understanding of best practices in frontend architecture and performance optimization.
==[Nice to Have]==
Some backend familiarity (basic Python/Django for minor adjustments).
Previous work on fast-paced startup MVP development.
So it's not so much about forcing truly international companies to pay taxes in the US (though they should pay taxes if they are indeed subsidiaries making money from the work of a parent company when that parent company repatriates profits), it's more about exposing the legal-by-letter-but-not-by-spirit practices of companies that hide money generated in the US overseas.
See http://www.npr.org/2011/03/17/134619750/how-offshore-tax-hav...
Apply: http://bit.ly/hve1AT
We're looking for a junior/mid level software engineer with an ability to work on front and back end code. We have a Rails/Javascript UI that uses a RESTful service built with Java (Spring, Hibernate, RESTlet) as its datastore.
Our team runs as closely to a startup as you can in the academic environment. We're responsible for building BioPortal: http://bioportal.bioontology.org. This isn't one of those research projects that produces a ton of theory but nothing usable. We're responsible for a full production environment that gets tens of millions of hits a month and have a full team of developers, including proper managers and even some QA (this is huge in academia). The project is well-funded by the NIH and we're halfway through year one of a five year grant.
You'll have a huge say in how things get implemented. We're not scared to incorporate new tech and definitely appreciate what people have to bring to the table. You'll be encouraged to get things done with minimal supervision, but everyone on the team is excited about talking through problems as needed.
Stanford Pros:
* Competitive compensation. Stanford likes to hire the best and we know we're competing with Google, Facebook, and everyone else. Salaries are competitive, obviously no access to options, bonuses, or profit-sharing :)
* Awesome benefits. This makes up for the lack of compensation to me. We get three weeks of vacation plus sick time plus PTO plus holidays. There's a two-week closure every December. Amazing health plans,. Free Caltrain and VTA. Alternative transit compensation. Healthy living incentives. Access to classes, gyms, libraries, and anything else the Stanford community has to offer.
* The work is incredibly meaningful and not profit-driven. Nothing wrong with profit, but if you're interested in just jumping into challenging work without worrying about money it can be a benefit.
* You work with people who are the best in the world at what they do.
* Travel opportunities for conferences on occasion.
Questions: palexander@stanford.edu
edit: formatting
http://data.gov.uk/apps - same thing here, driven by the semantic web and linked data.
And here's Gawker's official response: http://gawker.com/5712615/commenting-accounts-compromised-++...
We're hiring people interested in working with semantic web technologies, including RDF, OWL/OBO ontologies, triple stores, Protege, etc. The positions are mainly senior right now, possibly junior in the near future. Our main product is BioPortal, an ontology repository site with a RESTful API.
Stanford is an amazing place to work, great benefits, competitive salary, and the team here is top-notch (as you would expect). Feel free to ask questions (email in profile).
Apply online: http://bit.ly/9HBcMB
Edit: no telecommute (Stanford policy I believe)
Public transit isn't as good as NYC or Chicago, but it's decent.
I haven't heard of any major incidents of compromise, though it is easy to let sites get out of date which would leave some holes open.
As for MySQL, I think there are plenty of examples of it working at massive scale with good security (inside the Drupal community and out). From what I've seen developers seem pretty committed to working with other databases, though I'm not sure how far beyond MySQL and Postgres you'll get.
As for the "effective as an MVC question": no. Looking at that chart, half of the items mentioned in the Controller and Model you aren't supposed to edit regularly (parts of the Drupal Core), and especially not for site-specific functionality. Sure, most things can be altered with the addition of modules, but you're eventually going to run across something that can't be easily overridden from a module, or a place where there's no hook, or you just fundamentally disagree with how something works.
The modules themselves can be just as frustrating. Sometimes you'll encounter a situation where a module gets you 95% of the way there, but again you'll need to make some alterations and you have to understand exactly how the module works in order to do this. That means delving into someone else's code, the quality of which can vary considerably.
Finally, Drupal isn't REALLY object oriented. It's not as if content types are represented as a model with a corresponding controller, which is how I would expect MVC to work. A lot of individual pieces of code are OOP, but the entire system wasn't designed with this in mind.
That's not to say that Drupal doesn't have its uses. If you are fine with the default that's provided or feel like getting 95% of the way there in some cases is good enough, then by all means fire up a Drupal site. Unfortunately, you need to be familiar with the options out there in order to easily make the decision up front.
On the plus side, it's nice having a user system with permissions, administration, easy ways to add content, pretty good methods for handling audio, images, etc all up-front without having to do any coding. This is where Drupal shines, in my opinion. It's great for enabling technical people who can't/don't code to set up complicated systems. But that's a far cry from being an effective MVC.
If you do use Drupal, definitely use Drush (http://drupal.org/project/drush).
Not to say that his argument couldn't fly, but I'm not sure I would give it that much credence either.
I've been thinking of throwing the code up somewhere for people to try. Let me know if there would be interest in that.
As a shopping mall, it's great. As a neighborhood, which it certainly aspires to, it sucks.
Since the link focused on the negatives, I'll throw some positives out there (coming from a San Jose native who has lived in SF, LA, Chicago, and now Morgan Hill - mushroom capital of the world).
1. There are some cool little neighborhoods in the San Jose metropolitan area: Willow Glen, Rose Garden/Burbank, Campbell, Saratoga, Almaden Valley.
2. Good ethnic food, especially from Latin America, Vietnam, India, and China. Even some good fine dining opportunities (La Foret in New Almaden comes to mind).
3. A great Latino/Chicano cultural scene.
4. Decent transit that's been getting better (much, much better than LA, lagging a little behind SF and WAY behind Chicago/New York).
5. Retail tech stores all over (even SF lacks this).- Central Computer, any number of Fry's.
6. A developing downtown. If you'd been here ten years ago, this place was dead. If you'd been here 20 years ago...well, you wouldn't have been downtown. The fact that you can go there at night at all now is AMAZING considering what this place was like when I was a kid. It's fairly jumping now, with a decent selection of restaurants and good parking.
7. Cheaper than SF by a bunch.
San Jose is great, especially if you aren't into the trendy hipster scene and don't mind heading into "scary" (aka non-Anglo) parts of town like East San Jose, Little Saigon, etc.
"But if the creator of the work is not an employee, but instead a freelancer, than the "work made for hire" requirements of the independent contractor prong must be satisfied. This means that the work must be specially ordered or commissioned by the publisher, the work must fall into one of the nine enumerated categories of work, and there must be a signed writing between the parties where they agree that the work will be considered a "work made for hire."
I can think of a couple of reasons:
1. Access to grant funding. It's really hard to get granting organizations to take you seriously if you are applying for monies unattached.
2. Teaching load actually isn't that much of a concern for people at big research universities. One of my mentors described it like this: you have "cosmopolitan" professors and "hometown" professors. The cosmopolitans are always presenting their work, speaking at conferences where they were invited, and bringing in huge grants. They don't do much committee work, they don't have teaching loads (or, when they do, they hire someone to do the teaching for them). This leaves them plenty of time to concentrate on writing (or managing their ghostwriters aka grad students, spouses, research assistants, etc), presenting, researching, and publishing. The hometown faculty actually do all of the "dirty" work of running the university: sitting on committees, teaching, designing policy, etc.
3. They do get a cadre of grad students to help them out. Basically, they get to hand-pick a research team and work with them for 3-10 years (this happens more at large research universities and with senior faculty). These students are there to work with you because their interests and/or past work somehow connect with what you are doing (research interests, publication plans, lab work, etc).
4. Teaching a graduate-level seminar isn't like teaching an intro to technology or English 101. It's mentally tough and rigorous for everyone involved, including (and, you might argue, especially) the faculty. You have to be on your game, every week. And good faculty will use these seminars to develop and flesh out new ideas, concepts, and arguments. Like your cadre of grad students, this is another place where you get to exchange ideas on things that YOU are interested in.
That's just a couple of the reasons I think people go into it. However, I do think that opportunities to do work at this level will continue to shrink as universities are seen, more and more, as a place where you go to get trained for a job. It isn't too distant in the future that we will start seeing standardization movements in higher ed. Then you'll get everyone teaching to the test rather than their passions.
And I tend to agree with his analysis: money is flooding to an ever-increasing administrative layer while more and more classes are taught by "cheap" adjunct faculty who have zero job security and no opportunity for professional development. In his estimates, and for sure at the California state school I am most familiar with, adjuncts are now teaching 70-75% of courses, compared with rates as low as 20-25% in the past.
(Disclaimer: I'm a former adjunct university teacher :)