File size: 6,753 Bytes
66d63c7
4d76ff8
66d63c7
c3ee309
 
 
66d63c7
c3ee309
66d63c7
d3f86a4
 
 
1549063
 
1194d1e
1549063
 
1194d1e
1549063
 
 
 
 
 
 
 
d3f86a4
4d76ff8
c3ee309
 
 
4d76ff8
 
 
c3ee309
d3f86a4
 
4d76ff8
 
 
d3f86a4
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
4d76ff8
 
d3f86a4
1549063
4d76ff8
 
 
1549063
 
 
c3ee309
 
 
4d76ff8
1549063
4d76ff8
ed10886
c3ee309
 
4d76ff8
1549063
 
ed10886
1549063
ed10886
 
1549063
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
import gradio as gr
from joblib import dump, load

from sklearn.feature_extraction.text import TfidfVectorizer
from sklearn.feature_selection import SelectKBest
from sklearn.feature_selection import f_classif

import pandas as pd

from textblob import TextBlob
import textstat

titulo1 = """CLONE - Studio Dashboard: "default" and "Default Project" does not give clear information about Alloy and Project unless description is read."""
descricao1 = """Steps To Reproduce: 1. On dashboard on studio 3.0, navigate to Develop tab. 2. Notice "default" and "Default Project" & "two-tabbed" and "Tabbed Application" names. Actual: User does not get clear information from names that one is alloy project and another one is Titanium project unless he reads the description below. Expected: Naming convention or icon corresponding must suggest type"""

titulo2 = """Ti.UI.Picker has no collection binding"""
descricao2 = """h3. original discussion http://developer.appcelerator.com/question/145992/databinding-on-picker h3. problem Collection binding is not implemented for Ti.UI.Picker as it is for Ti.UI.TableView and other generic Titaniums views (View, Window, ScrollView, etc...). h3. solution Support collection binding on Ti.UI.Picker just as it is on TableView. It will need special handling as the Ti.UI.Picker requires custom parsing for columns and rows. Something like this should be how it would work for devs: {code:xml} <Alloy> <Collection src="book" /> <Window class="container"> <Picker dataCollection="book"> <PickerRow title="{title}" /> </Picker> </Window> </Alloy> {code}"""

titulo3 = """Enable more complex notation in binding"""
descricao3 = """Allow developers to use syntax like the following in collection/model bindings:    {code:xml}  <Alloy>      <Model src=""someModel""/>      <Window title=""{someModel.title} {someModel.subtitle}""/>  </Alloy>  {code}    Basically, instead of assuming the whole property needs to be wrapped in \{\}, allow developers to put as many of them in the attribute as they want."""

titulo4 = """Orphan file cleanup deletes builtins and widget assets"""
descricao4 = """During the compile process Alloy will attempt to remove files from the Resources directory that are no longer present anywhere in the ""app"" folder. Alloy searches a number of locations in the ""app"" folder to see if the file is an orphan or not. False negatives should be avoided as they will leave unused files in the project. False positives on the other hand are not really worrisome since those resources will be recreated on the next compile anyway.     With that in mind, there are currently false positives for orphan file deletion for builtins and widgets. Builtins and widgets will be pulled in fresh each time. Again, this will not negatively impact a developer's build process or app in any way, it would just be more true to the logic if these files were left alone during the orphan cleanup phase."""

titulo5 = """Resolve suboptimal compression from uglify-js v2 update"""
descricao5 = """The v2 update of uglify-js in Alloy, specifically version 2.2.5, has some suboptimal compressions, which are causing the optimizer.js test spec to fail in certain cases. Specifically the issues are around booleans and cascading of variables in assignments. These issues have been logged with the Uglifyjs2 project in the following links:    * https://github.com/mishoo/UglifyJS2/issues/137  * https://github.com/mishoo/UglifyJS2/issues/138    When these issues are resolved and distributed in an npm release, we need to revisit these compressions and testing to ensure that the fixes are in place, and that new uglify-js version has no regressions that impact alloy."""

def calcula_MbR(titulo, descricao):
    context = titulo + descricao
    d = {"context": [context]}
    df = pd.DataFrame(data=d, columns=["context"])
    model = load("model/model_tawos_aloy_mbr.pkl")
    story_points_MbR = model.predict(df["context"])
    return story_points_MbR

def calcula_neosp(titulo, descricao):
    model = load("model/model_tawos_aloy_neosp.pkl")
    context = titulo + descricao
    d = {"context": [context]}
    df = pd.DataFrame(data=d, columns=["context"])

    # features de legibilidade
    df["gunning_fog"] = df['context'].apply(textstat.gunning_fog)#
    df["flesch_reading_ease"] = df['context'].apply(textstat.flesch_reading_ease)#
    df["flesch_kincaid_grade"] = df['context'].apply(textstat.flesch_kincaid_grade)#
    df["smog_index"] = df['context'].apply(textstat.smog_index)
    df["coleman_liau_index"] = df['context'].apply(textstat.coleman_liau_index)#
    df["automated_readability_index"] = df['context'].apply(textstat.automated_readability_index) #
    df["dale_chall_readability_score"] = df['context'].apply(textstat.dale_chall_readability_score)#
    df["difficult_words"] = df['context'].apply(textstat.difficult_words)
    df["linsear_write_formula"] = df['context'].apply(textstat.linsear_write_formula)#

    # feature de sentimento
    df["polarity"] = df["context"].apply(lambda x: TextBlob(x).sentiment.polarity)
    df["subjectivity"] = df["context"].apply(lambda x: TextBlob(x).sentiment.subjectivity)

    X = df[["gunning_fog", "flesch_reading_ease", "flesch_kincaid_grade", "smog_index", "coleman_liau_index", 
            "automated_readability_index", "dale_chall_readability_score", "difficult_words", "linsear_write_formula", 
            "polarity", "subjectivity"]]

    story_points = model.predict(X)
    return story_points
    
def calculaTFIDFSVM(titulo, descricao):
    model = load("model/model_tawos_aloy_tfidfsvm.pkl")
    context = titulo + descricao
    d = {"context": [context]}
    df = pd.DataFrame(data=d, columns=["context"])
    vectorizer = load("model/vectorizer_tfidf.pkl")
    X = vectorizer.transform(df["context"])
    
    story_points = model.predict(X)
    return story_points

def calcula(titulo, descricao):
    return calcula_MbR(titulo, descricao), calcula_neosp(titulo, descricao), calculaTFIDFSVM(titulo, descricao)

demo = gr.Interface(fn=calcula, 
                    inputs=[gr.Textbox(placeholder="Título", label="Título"), 
                            gr.Textbox(lines=10, placeholder="Descrição", label="Descrição")], 
                    outputs=[gr.Textbox(label="Story Points Estimado MbR"),
                             gr.Textbox(label="Story Points Estimado NEOSP-SVR"),
                             gr.Textbox(label="Story Points Estimado TFIDF-SVR")],
                    title="Agile Task Story Point Estimator - TAWOS - Alloy",
                    examples=[[titulo1, descricao1], [titulo2, descricao2], [titulo3, descricao3], [titulo4, descricao4], [titulo5, descricao5]]
                    )

demo.launch(server_port=8080)