[polymer-dev] Fwd: Multiple Jobs Data Modeler / Application Support Analyst / Senior Tester / Business Architect Analyst
Hi please do send your resumes to vrenikun...@goavancer.com We have Data Modeler- Level III job opening for 3 Months Contract in Washington DC if your are seeking to apply please do send your resume in word format and let me know best time to reach you to discuss for more about the job opportunity. Job Title:Data Modeler- Level III Duration: 3 months Job Location:Washington DC Client: World Bank Job Description / Responsibilities: Strong background in Data Architecture including data warehouse design, extract-transform-load (ETL) design and development. Very strong with RDBMS like Oracle and SQL Server.· Must have experience in creating and maintaining end to end data architectures; logical, access, and physical data modeling; normalized and dimensional data modeling techniques; data analysis and mapping; and creation and usage of metadata. Working knowledge of modeling tools (e.g., Computer Associates (CA) AllFusion, ERWin Model Manager, IBM Rational Suite, Rational (RSA RDA) Hands-on technical experience using data warehouse, business intelligence and analytics products. Attention to detail, commitment to quality work, and ability to manage multiple functional objectives and priorities. Leadership experience working in a matrix organization. Strong access modeling/SQL Query skills leaning towards the physical data modeling practice a plus. Master’s degree in Computer Science, Finance, MBA or related field and a minimum of 8 years relevant experience providing IT enabled solutions to financial institutions. Mature understanding of core applications used within the Bank group. Must be a seasoned technical expert with a strong business acumen, having in-depth understanding of the principles and practices of IT, and a strong _ Hi We have Application Support Analyst job opening for 12 Months Contract in Bothell, WA if your are seeking to apply please do send your resume in word format and let me know best time to reach you to discuss for more about the job opportunity. Job Title:Application Support Analyst Duration: 12 months Job Location:Bothell, WA Job Description / Responsibilities: Perform monitoring, troubleshoot the system issues and configuration activities to support and manage production servers which includes Tibco and Weblogic activities. Experience on Tibco BW, Tibco EMS, Tibco Hawk, Tibco Administrator, Weblogic, WLST, Java, JMS, JMX, Oracle ESOA, Load Balancer (F5 and A10), UNIX and Windows environments. Extensive experience with UNIX commands, SSL certificates and monitoring tools like HP BSM, HP OVO, Intrascope. Good Analytical and communication skills along with extensive experience of working in Operation / production Support. To follow up, troubleshoot and resolve tickets raised by client, and other teams. To document and perform knowledge transition to the team and implement best practices to reduce the recurrence of the tickets. Eagar to learn and update self on the latest tools and technologies. To automate some of the recurring processes, tasks to reduce the manual Experience: 4 plus Years Thanks Regards _ Hi We have Senior Test lead job opening for 12 Months Contract or Permanent in San Antonio, TX if your are seeking to apply please do send your resume in word format and let me know best time to reach you to discuss for more about the job opportunity. Job Title:Test lead with ALIP testing experience Duration: 12 months Job Location:San Antonio, TX Job Description: Experience in ALIP implementation as a test lead or QA lead (Mandatory Skills ALIP Product-(Accenture Life Insurance Platform) Experience in life domain and life products Certification in life domain Need to demonstrate the QA lead skills to implement ALIP product by replacing the existing in house system. Responsibility: test strategy preparation, test plan preparation, automation plan, test execution, defect management, project status updates to customers. Thanks Regards _ Hi We have Business Architect Analyst III (Senior) job opening for 3 Months Contract in Washington, DC if your are seeking to apply please do send your resume in word format and let me know best time to reach you to discuss for more about the job opportunity. Job Title:Business Architect Analyst III (Senior) - Onsite Duration: 3 months Job Location:Washington, DC The expected work products for this engagement include: · Document eliciting Business and IT Strategy Vision for MIGA · IT Architectural road map for MIGA (iGuarantee Roadmap) · Business strategy and Business process work outputs · Gap Analyst of Current state and Target state · Define comprehensive IT road map for MIGA · Build maintenance manuals
[polymer-dev] Re: How to add {{parameter}} in the iron-ajax 'url' property?
iron-ajax id=get_file
handle-as=text
last-response={{fileContent}}
headers='{accept: application/vnd.github.VERSION.html}'
on-response=handleFile
on-error=handleFileErrorResponse
/iron-ajax
ready: function() {
this.$.get_file.url = https://api.github.com/repos/; + this.owner +
/ + this.repo + /contents/ + this.fileName + ?ref= + this.branch +
access_token= + this.tk;
this.$.get_file.generateRequest();
},
This works for m.
On Monday, May 18, 2015 at 1:00:13 AM UTC-7, Christian Tzolov wrote:
The core-ajax element allows binding parameters in the url property:
core-ajax url={{hostname}}/hawq-api/v1/version handleAs=json response
={{resp}}/core-ajax
In iron-ajax this is not possible anymore. It seems that iron-ajax's url
expect a static string. Is there a new way to compose dynamic urls in
iron-ajax?
Thanks
Follow Polymer on Google+: plus.google.com/107187849809354688692
---
You received this message because you are subscribed to the Google Groups
Polymer group.
To unsubscribe from this group and stop receiving emails from it, send an email
to polymer-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/polymer-dev/acc49140-d438-40c8-bd15-e961b8a6e1c8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [polymer-dev] localDom API and other libraries
On Mon, May 18, 2015 at 5:46 PM, Eric Eslinger eric.eslin...@gmail.com wrote: One of the really rad things about Polymer (0.5) and webcomponents is that everything is just DOM. You can pretty easily use core- and paper- components libraries inside of an (say) angular app to render out content. Doesn't matter if you're using jQuery raw or ember or what have you- DOM is DOM, and it mostly works (modulo some property / attribute bindings) The new localDom API seems to indicate that this may no longer be the case- if I'm redistributing DOM content, I need to use the polymer dom interface, rather than just plain parent/child/append calls on document. This seems to indicate that modern polymer isn't going to be compatible with angular, or with any other library that manipulates the DOM, or is it the case that this only matters when there's more complicated shady/light manipulations? The full answer is that there are a range of options with various trade-offs, and for Polymer.dom() there will be a set of workarounds for integration with various libraries. The best option, if available, is native Shadow DOM. But that's not so interesting because everything just works :) So, without native, there are now two options: Shady DOM and Shadow DOM polyfill. It's important to note that you can still use the full polyfill. The polyfill has the upside that it's _mostly_ compatible with existing code (there are some cases that aren't wrapped, like `document`). The downside is that it's slow, possibly unacceptably slow in mobile Safari, say. Shady DOM is fast, but brings up the compatibility issue. But... we've done experiments with making other libraries use Shady DOM and it looks like it'll work well enough in a lot of situations. One strategy is custom adapters. Angular2 for instance has a complete DOM abstraction so that it can use different APIs, like virtual DOM and Dart's dart:html. It's really trivial to implement a Shady DOM version, and it all works as expected. I'm guessing that virtual-dom-ish oriented frameworks like React and Ember will be amenable to this kind of adaptor, though they may not be as easily hookable as Angular2. Another strategy is patching just enough of the DOM APIs to make a framework happy. We think we can do enough for React, since it uses a pretty small portion of the DOM APIs. As an example, if I have content in the drawer part of a paper-drawer-panel, and then, using jquery or some other element selector, inject nodes inside of the already-projected menu div, will this break things? Or is it only the case that I need to use the local DOM api when if I'm changing the nodes that would be selected as content to project (and not their child nodes)? Is there some way to shim the document-level query selectors in there or add a mutation observer that calls distributeContent as needed? I'm guessing it was this shimming and mutation observer that contributed to the slowness of 0.5 in non-chrome browsers. Exactly, but again the full polyfill is still available. I've got next week blocked out to actually work on getting angular 1.4 to play nice with polymer 0.9 (we use angular to build the page and manage data, and polymer for handy flexbox directives and material design ui bindings). So I guess I'll figure it out then. I'm guessing that Angular1 will be a little harder to get working than Angular2, but since I know my way around Angular a _little_, I'd be very happy to help out. Cheers, Justin e Follow Polymer on Google+: plus.google.com/107187849809354688692 --- You received this message because you are subscribed to the Google Groups Polymer group. To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/CABsi40JyUq76PSwF%2Bxx_k9CXcJtJmnXEOVXstdQu6BVRoYRc6g%40mail.gmail.com https://groups.google.com/d/msgid/polymer-dev/CABsi40JyUq76PSwF%2Bxx_k9CXcJtJmnXEOVXstdQu6BVRoYRc6g%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. Follow Polymer on Google+: plus.google.com/107187849809354688692 --- You received this message because you are subscribed to the Google Groups Polymer group. To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/CAEKsHmCE5qMh6anu9RBs3a8vSteYZaWn%3DKxrvvb96yd4CVH7LA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [polymer-dev] Curly braces vs. square braces
There are no official guidelines. I think for the most part it's a style
thing, and at the moment what you see in the docs may depend on who first
wrote the example. There are two basic schools of thought:
School #1) Curly braces are automatic -- in almost all cases, they just
do the right thing. Use 'em everywhere unless you specifically want to rule
out the possibility of a two-way binding. (You'll see that a lot of the
docs are written this way, partly for historical reasons -- 0.5 had only
the curly brackets.)
School #2) Using square braces for all one-way bindings makes it easy to
see the expected data flow. So use square brackets everywhere and only use
curly brackets where you specifically want a two-way binding. (Most of the
new elements follow this style.)
I'm not aware of big performance implications either way. I'd say pick your
style and stick to it.
Cheers,
Arthur
On Fri, May 15, 2015 at 2:57 PM, michae...@chromium.org wrote:
Is there a guideline for when to use curly vs. square braces, when the
effect would be the same?
For example PRIMER.md uses curly braces for text content, but it's just a
one-way binding:
span{{first}}/span
Computed bindings are another example. PRIMER.md uses curly braces, which
seems confusing because it's not really two-way binding:
x-child some-property={{getValue(otherThing)}}
Finally in one-way downward binding (notify: true is not set on a
property), using curly braces won't result in the host property being
updated.
Are there any performance reasons to use one or the other? Or suggested
style or forward-compatibility reasons?
Follow Polymer on Google+: plus.google.com/107187849809354688692
---
You received this message because you are subscribed to the Google Groups
Polymer group.
To unsubscribe from this group and stop receiving emails from it, send an
email to polymer-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/polymer-dev/fdb138e1-dc82-420a-9d10-ec0d55a715cc%40googlegroups.com
https://groups.google.com/d/msgid/polymer-dev/fdb138e1-dc82-420a-9d10-ec0d55a715cc%40googlegroups.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
Follow Polymer on Google+: plus.google.com/107187849809354688692
---
You received this message because you are subscribed to the Google Groups
Polymer group.
To unsubscribe from this group and stop receiving emails from it, send an email
to polymer-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/polymer-dev/CADSbU_xM2d%3Db54W-NNXv7hi2D27pL%2BrFVrL5BaFy_U-u7UuUZw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
[polymer-dev] property's accepted values
Just musing to myself I wondered if there exists currently or on the roadmap the ability to specify a set of values a particular property may accept. This would be similar to other languages' `enum` type where you specify up-front all the possible values and the implementation refuses to accept things outside of those values. Another idea is a regular expression validator on incoming values. My idea is that if a component's property is set to an invalid value by one of these two validations then the component code we write ourselves is never notified of the change and it is silently ignored. This would allow component authors to be sure that values they receive are correct without having to write boilerplate to actually verify that fact. Thinking about a possible implementation I suppose a validator-proxy component could be created which encapsulates all the required validation in generalised terms which takes an input value, a default, and either a regex or list of accepted values and has an output property which will only ever contain normalised values. Then we can even create a series of known-good intermediate implementations of the validator-proxy which contains pre-build validations for things like css colours, telephone numbers etc. which just take a single input and give a single validated output without the requirement to write the regex every time an author wants a common validation. In fact I might just go ahead and write that component while I'm faffing around... P.S. 4am coding is always good for these random ideas! Oh it's nearly 4am (3:30) now :-p Follow Polymer on Google+: plus.google.com/107187849809354688692 --- You received this message because you are subscribed to the Google Groups Polymer group. To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/35c3ddaf-ea44-490b-8821-513585c45b7e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [polymer-dev] Custom HTML elements as layouts?
Ah. So, yes, if you do that, the content element won't work.
One of the main problems shadow DOM is designed to solve is composition.
Without shadow DOM (or the shady DOM shim in 0.9+), you don't have content
projection.
So I guess the question is: what are you trying to achieve by putting the
template in the light DOM?
Thanks,
Arthur
On Sun, May 17, 2015 at 6:10 PM, DS Morse david.mo...@issinc.com wrote:
I was referring to then we place the polymer elements into the light
(which was quite difficult in 0.5)
/**
* Override the parseDeclaration to force this template
into the light DOM
*/
parseDeclaration: function(elementElement) {
var template = this.fetchTemplate(elementElement);
$(this).empty();
if (template) {
this.lightFromTemplate(template);
}
},
Based on a quick read of the 0.9 docs, it looks like it might be much
easier.:
https://www.polymer-project.org/0.9/docs/devguide/local-dom.html#dom-distribution
But the problem was html that looked like this
x-foo
x-barh1hello world/h1/x-bar
/foo
Where foo was a polymer element which we had placed into the light dom
(using the above code) then we could not include content in the x-foo
template, which made it very difficult to insert the composed content.
On Sunday, May 17, 2015 at 3:51:14 PM UTC-6, arthure wrote:
I'm not sure exactly what you mean. Do you mean when the *element* is in
the light DOM,
or when the *content* tag is in the light DOM?
The 0.5 intro tutorial (
https://www.polymer-project.org/0.5/docs/start/tutorial/intro.html) has
polymer
elements in the light DOM, as does the 0.9 quick tour:
picture-frame
image src=images/p-logo.svg
/picture-frame
Here both picture-frame and the image tag are in the document's
light DOM,
but the image is projected into the picture-frame's insertion point.
The content tag *itself* must be inside an element's shadow DOM to do
anything.
It's function is to give an element's *light DOM children* (like image
above) an
*insertion point* into the element's shadow DOM.
On Sat, May 16, 2015 at 6:07 PM, DS Morse david...@issinc.com wrote:
I've never been able to get the content tag to work unless the polymer
element is in the shadow dom. Has anyone gotten it to work when the
component is in the light?
On Friday, May 15, 2015 at 12:34:03 PM UTC-6, arthure wrote:
What you're looking for is the content tag. You can see it in use
here:
https://www.polymer-project.org/0.9/docs/start/quick-tour.html
See the third sample down, Composition with local DOM.
More details here:
https://www.polymer-project.org/0.9/docs/devguide/local-dom.html#dom-distribution
-Arthur
On Fri, May 15, 2015 at 10:56 AM, Julien Silland jsil...@gmail.com
wrote:
Heads-up: this could be more of a question for the group in which HTML
custom elements are discussed but I figure the intersection with Polymer
developers is rather large —
I'm trying to understand whether it is possible to declare a custom
HTML element that can wrap arbitrary subelements and 'yield' the rendering
of those subelements at a determined insertion point. The syntax below is
approximative but should provide a goods idea of what I'm trying to do
my-list header=My Header footer=My Footer
lifoo/li
libar/li
/my-list
dom-module id=my-list
template
p{{header}}/p
ul
!-- what goes here? can I automatically insert the lis
declared above?
/ul
p{{footer}}/p
/template
/dom-module
This is a simple example — in the greater scheme of things, I'd like
to be able to insert/handle arbitrary content whose type may not be known
ahead of time (e.g. a div or my-other-element, etc…).
Basically I'd like to know whether custom HTML elements have the
possibility to act as external layouts for other elements as opposed to
just encapsulated templates.
Cheers,
-Julien
Follow Polymer on Google+: plus.google.com/107187849809354688692
---
You received this message because you are subscribed to the Google
Groups Polymer group.
To unsubscribe from this group and stop receiving emails from it, send
an email to polymer-dev...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/polymer-dev/CAKyYh8A_JxkjbFiqxfyUqjs_NknSrNvMo1_ORXwfDtt7gggNBg%40mail.gmail.com
https://groups.google.com/d/msgid/polymer-dev/CAKyYh8A_JxkjbFiqxfyUqjs_NknSrNvMo1_ORXwfDtt7gggNBg%40mail.gmail.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
Follow Polymer on Google+: plus.google.com/107187849809354688692
---
You received this message because you are subscribed to the Google
Groups Polymer group.
To unsubscribe from this group and stop receiving emails from it, send
an email to
Re: [polymer-dev] localDom API and other libraries
One of the really rad things about Polymer (0.5) and webcomponents is that everything is just DOM. You can pretty easily use core- and paper- components libraries inside of an (say) angular app to render out content. This is truly the great promise of Web Components, and will be completely true when Shadow DOM is native in all browsers. However, up to now, we've only had the Shadow DOM polyfill on non-supporting browsers. The Shadow DOM polyfill is a great piece of code, but it only approximates the interoperability we crave. There are numerous cases where the polyfill falls over: it has never been fire and forget. More specifically, the Shadow DOM polyfill is extremely invasive: it wraps the majority of the DOM api in JavaScript. This is an imperfect task which leads to an interoperation mine-field, and dramatically degrades performance. Additionally, the Shadow DOM polyfill makes no attempt to simulate Shadow DOM CSS scoping, so styling fidelity vs native Shadow DOM is poor. Ultimately, we decided that providing users with a Polymer experience that was sufficiently robust for production code required a different solution that the Shadow DOM polyfill, and Shady DOM was born. Shady DOM is compatible with native Shadow DOM, has a more robust CSS scoping facility, and is dramatically more performant. We feel good suggesting that developers can build and ship products using Shady DOM, a bar we never quite surmounted with the Shadow DOM polyfill. As I mentioned at the outset, the true promise of Web Component will not be achieved until Shadow DOM is truly native across browsers. The great news is that all major browser vendors are actively working towards this goal. Go take a look at the recent discussions on public-webapps https://lists.w3.org/Archives/Public/public-webapps/ mailing list if you want to see the sausage being made. Users interested in Web Components are encouraged to chime in and let the browser vendors know their feelings on the importance of Shadow DOM interoperation. Scott On Mon, May 18, 2015 at 5:46 PM, Eric Eslinger eric.eslin...@gmail.com wrote: One of the really rad things about Polymer (0.5) and webcomponents is that everything is just DOM. You can pretty easily use core- and paper- components libraries inside of an (say) angular app to render out content. Doesn't matter if you're using jQuery raw or ember or what have you- DOM is DOM, and it mostly works (modulo some property / attribute bindings) The new localDom API seems to indicate that this may no longer be the case- if I'm redistributing DOM content, I need to use the polymer dom interface, rather than just plain parent/child/append calls on document. This seems to indicate that modern polymer isn't going to be compatible with angular, or with any other library that manipulates the DOM, or is it the case that this only matters when there's more complicated shady/light manipulations? As an example, if I have content in the drawer part of a paper-drawer-panel, and then, using jquery or some other element selector, inject nodes inside of the already-projected menu div, will this break things? Or is it only the case that I need to use the local DOM api when if I'm changing the nodes that would be selected as content to project (and not their child nodes)? Is there some way to shim the document-level query selectors in there or add a mutation observer that calls distributeContent as needed? I'm guessing it was this shimming and mutation observer that contributed to the slowness of 0.5 in non-chrome browsers. I've got next week blocked out to actually work on getting angular 1.4 to play nice with polymer 0.9 (we use angular to build the page and manage data, and polymer for handy flexbox directives and material design ui bindings). So I guess I'll figure it out then. e Follow Polymer on Google+: plus.google.com/107187849809354688692 --- You received this message because you are subscribed to the Google Groups Polymer group. To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/CABsi40JyUq76PSwF%2Bxx_k9CXcJtJmnXEOVXstdQu6BVRoYRc6g%40mail.gmail.com https://groups.google.com/d/msgid/polymer-dev/CABsi40JyUq76PSwF%2Bxx_k9CXcJtJmnXEOVXstdQu6BVRoYRc6g%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. Follow Polymer on Google+: plus.google.com/107187849809354688692 --- You received this message because you are subscribed to the Google Groups Polymer group. To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/CAHbmOLbdqhZZ42M%3Dd42F65ntgJvnERAxNqNt7%3DtFZR9qqnBxgA%40mail.gmail.com. For more options, visit
